Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[16.0][PERF] Improve journal ledger performance with lots of lines #1287

Open
wants to merge 1 commit into
base: 16.0
Choose a base branch
from

Conversation

hugosantosred
Copy link
Member

Improves the performance when obtaining the Journal Ledger with lots of account moves and lines.

For example in a demo database with 475K customer invoices before this changes the report in xlsx format is generated in 1900 seconds. With this changes is generated in 120 seconds

@hugosantosred hugosantosred force-pushed the improve-journal-ledger branch 2 times, most recently from af5aceb to b5a4bd5 Compare February 13, 2025 11:02
Copy link
Contributor

@aritzolea aritzolea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review. Thanks a lot for this huge performance improvement!

Copy link

@liebana liebana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functional review, LGTM.

@pedrobaeza pedrobaeza added this to the 16.0 milestone Feb 17, 2025
@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

Copy link
Member

@pedrobaeza pedrobaeza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better this way, thanks. The only missing thing is to comment in code before all the .id stuff that this technique is used for avoiding continuous recordset recreation, which affects dramatically the performance on systems with huge amount of journal items. This way, you avoid that in the future someone is tempted to restore the recordset thing.

@hugosantosred
Copy link
Member Author

Better this way, thanks. The only missing thing is to comment in code before all the .id stuff that this technique is used for avoiding continuous recordset recreation, which affects dramatically the performance on systems with huge amount of journal items. This way, you avoid that in the future someone is tempted to restore the recordset thing.

Added the comment in the exigibility check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants