Thursday, April 9, 2026
1 change · saas-18.4
Enhancements to existing features
Accounting screens that show running balances now load using far less memory by only calculating balances for the records being viewed. This prevents crashes on very large accounting datasets and improves response times for heavy list views.
Original PR description
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move…
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move lines, the result returned by fetchall() hits the memory limit and the server crashes. We propose to encapsulate the original query to only return the result for the account move lines present in self. Benchmarks --------------- The following benchmarks were generated with a customization of the account.move.line list view to display the cumulated_balance field. Memory usage during the self.env.cr.execute and the dictionary population: | Operation | Before the fix | After the fix | |---------------|----------------|---------------| | populate dict | 1.5 GB | 17.1 MB | | execute query | 430 MB | 8.3 MB | 100 000 lines were displayed at the same time to get a significant size. So the number of records in self is more than 7 000 000 without the fix and 100 000 with the fix. Time spent in the _compute_cumulated_balance method: | No of AML | Before the fix | After the fix | |-----------|----------------|---------------| | 7 000 000 | 10.4 s | 6.8 s | opw-6053720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256658 Forward-Port-Of: odoo/odoo#255780