# optimizing reports

Andrew Sackville-West ajswest at mindspring.com
Fri Oct 5 23:28:52 EDT 2007

```Hi guys,

I'm bent on improving the speed of some of these reports and want to
bounce some ideas off you folks. The particular report I'm interested
in improving is the income statement. On my smaller file (133k) it
takes about 20 seconds to run a bog standard income statement. I
haven't timed it on my larger file (1.4M), but it takes way too

My investigation into this points to the function
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.

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. For example, giving this:

Toplvl---> A ---> A1
|->A2
|->A3
|->A4---->A4a
|->A4b

To calculate the balances of all these, it would calculate the whole
tree for the balance ot Toplvl; re-calculate all of A sub-tree to get A's
balance; re-calculate A1; re-calc A2; re-calc A3; re-calc the whole A4
sub-tree; then re-calc A4a; re-calc A4b etc etc etc... bad.

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. I
imagine the first walk would end up returning a list of toplevel
accounts, each member of which would be a cons of that account's
balance and a list of it subaccounts, each member of which would be a
cons... you get the idea.

So before I start hacking my fingers off, does this idea make sense?
(it does to me...) or is there something blatantly obvious that I'm
missing in this general idea? Also, if I'm mis-reading that code,
please let me know, but I think I have the gist of it pretty well.

A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20071005/c894592b/attachment.bin
```