optimizing reports

[Christian Stimming]

Am Samstag, 6. Oktober 2007 05:28 schrieb Andrew Sackville-West:
> I'm bent on improving the speed of some of these reports 

That's great! I think I've mentioned that before, but I'm also very unhappy 
with the current speed aka slowness of the text reports. I'm especially 
unhappy about that because my initial implementation of those was 
significantly faster, and only the rewriting of those reports by the changes 
mainly in r10078 (David Montenegro, June/July 2004) made them much slower 
(see my gnucash-devel msgs on 2006-06-20 and 2006-03-19).

> My investigation into this points to the function
> gnc:html-acct-table-add-accounts! in
> reports/report-system/html-acct-table.scm. This function appears to be
> the workhorse of the income statement but is also used in balance
> sheet, budget and trial balance reports, so fixing it would likely
> help those guys as well.

Yes. But we would have to find out more specifically the sub-functions where 
the CPU time is actually spent.

> Currently the report recurses through the account tree gathering
> totals for each account and it sub accounts. It appears that it walks
> all the way out to the leaf nodes at each level, so that the sub
> account totals get calculated repeatedly making this a hugely
> inefficient function. 

Yes. However, the previous implementation did exactly the same in terms of 
balance calculation. It is still available in html-utilities.scm's function 
gnc:html-build-acct-table and in particular add-group! there. 

For that reason I would believe the balance calculation itself doesn't seem to 
be the main problem. The main problem must be somewhere else around this... 
for example, the newer code might run the balance calculation on much more 
accounts than the old account; or the large (append env ...) statement in 
html-acct-table.scm:746 ff might consume a lot of time; or yet something 
else.

> I want to clean that up and what I'm thinking is to recurse through
> the tree once totalling up each relevant account and returning those
> totals in some structure that contains the accounts and their
> totals. Then walk through the tree generating the output table based
> on the required depth. This means I'd still be walking a tree
> structure twice, but I'd only be doing the per-account math once. 

Again, this might indeed help, but on the other hand this inefficiency was 
present in the earlier implementation and didn't seem to cause big problems 
there. 

It might still be reasonable to work on this part, but maybe it would pay off 
to examine a bit more whether this is really the trouble-causing part.

Christian