← Back to team overview

openerp-expert-accounting team mailing list archive

[Bug 568537] Re: The __compute method of account_account needs optmization to improve Accounting Performance!

 

Weird, pretty weird. 
The "brs = list(self.browse(cr, uid, ids2, context=context))" line was like that in the original, so your problem has nothing to do with the optimization! (the optimization is the one-liner "ids2.reverse()", and it won't fail unless the __compute method did already fail).

Ok, just found the problem; somebody did a pretty bad merge recently and
broke it:

They replaced:

206        ids2 = self._get_children_and_consol(cr, uid, ids, context)
207        acc_set = ",".join(map(str, ids2))
 
With: 

243       children_and_consolidated = self._get_children_and_consol(
244            cr, uid, ids, context=context)  


But didn't replace all the occurrences of "id2" with the new name "children_and_consolidated"! Ouch! Hey people, don't refactor the 'stable version' without testing!

I just filled a bug here: bug 589052

You may want to the version before the problem until it gets fixed (bzr
revert -r2745) [by the way, your ids2->ids change is wrong, you should
do ids2->children_and_consolidated instead)

-- 
The __compute method of account_account needs optmization to improve Accounting Performance!
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: Confirmed
Status in OpenObject Addons 5.0 series: Fix Released
Status in OpenObject Addons trunk series: Confirmed

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).