stimming at tuhh.de
Sat Oct 6 05:23:53 EDT 2007
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
> 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
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.
More information about the gnucash-devel