Ferdinand, somehow opening the chart of accounts is faster than getting
the root account values:

* Chart of accounts test:
   Without optimization:
          Elapsed to compute ['debit', 'credit', 'balance'] for accounts with 
code 1,2,3,4,5,6,7 => 1.08773589134
   With optimization:
         Elapsed to compute ['debit', 'credit', 'balance'] for account  
1,2,3,4,5,6,7 => 0.540276050568

101% faster (original/optimized = 2.01)


* Accounts list (first 80 accounts) test:
   Without optimization:
          Elapsed to compute ['credit', 'debit', 'balance'] for account 
0,1,10,100,1000000,...,4300498,4300502 => 2.84862804413
   With optimization:
          Elapsed to compute ['credit', 'debit', 'balance'] for account 
0,1,10,100,1000000,...,4300498,4300502 => 0.894719839096

218% faster  (original/optimized = 3.18)


* Search test (searching for accounts like '%700%'):
   Without optimization:
        Elapsed to compute ['credit', 'debit', 'balance'] for account 
700,7000,7000000,7000001,7001000,7002000 => 0.0230215191841
   With optimization:
        Elapsed to compute ['credit', 'debit', 'balance'] for account 
700,7000,7000000,7000001,7001000,7002000 => 0.0187527537343

22% faster (original/optimized = 1.22)


So I suppose the problem is that the performance hit grows with the number of 
account levels, it takes more time to get the values for the root account, that 
for all its childs. 
(And the Spanish chart of accounts has about five levels [43000001 is child of 
4300 which is child of 430 that is child of 43 child of 4 child of 0]).

-- 
The __compute method of account_account is wasting 78% of time
https://bugs.launchpad.net/bugs/568537
You received this bug notification because you are a member of OpenERP
Accounting Experts, which is a direct subscriber.

Status in OpenObject Addons Modules: New

Bug description:
The current __compute method of account_account is wasting a lot of time 
reordering the list of accounts to compute.

We can make the next block of code about five times faster with a small 
one-line optimization (just adding a "ids2.reverse()" line):

--------
        brs = list(self.browse(cr, uid, ids2, context=context))
        sums = {}
        while brs:
            current = brs[0]
            can_compute = True
            for child in current.child_id:
                if child.id not in sums:
                    can_compute = False
                    try:
                        brs.insert(0, brs.pop(brs.index(child)))
                    except ValueError:
                        brs.insert(0, child)
            if can_compute:
                brs.pop(0)
                for fn in field_names:
                    sums.setdefault(current.id, {})[fn] = 
accounts.get(current.id, {}).get(fn, 0.0)
                    if current.child_id:
                        sums[current.id][fn] += sum(sums[child.id][fn] for 
child in current.child_id)
--------     

That code is computing the value of each account as the sums of the account 
values plus its children values.

The problem is that the list of the accounts is sorted on the worst posible 
way! So most of time is wasted reordering that list.

The list of accounts comes from _get_children_and_consol, that returns a list 
of accounts in the form [parent, child1, child2, child1_of_child2, 
child2_of_child2, child3].
So the block of code shown above, that always tries to compute the first 
element of the list, but he won't be able to do it without computing the 
children accounts first: so it ends up poping accounts from the list and puting 
them back at the begining of the list in the reverse order... that is, it 
wastes a lot of time just to reverse the list on the most expensive way!

Adding a ids2.reverse() line before the block of code, will mean that the list 
of accounts will be in the form [child3, child2_of_child2, child1_of_child2, 
child2, child1, parent] so no poping&inserting will be necesary!

We have timed that block of code before adding the "ids2.reverse()" and after 
it:
                  
                      BLOCK                           FULL METHOD
Original:       2.1701090335825           2.370021998875  
Optimized:    0.37584179639849996   0.50867897272100004          (4.65 times 
faster!)

Note: Average times after several runs, getting the debit and credit of the 
root account on a database with 1663 accounts and 6930 account move lines.

I think this should be fixed ASAP: It will soothe the currents problems with 
accounting reports (like the general ledger performance problems reported on 
bug 514808 and bug 551630).



_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-accounting
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~openerp-expert-accounting
More help   : https://help.launchpad.net/ListHelp

Reply via email to