optimizing reports

[Andrew Sackville-West]

On Sat, Oct 06, 2007 at 11:23:53AM +0200, Christian Stimming wrote:
> 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).

I'll check those out. thanks.

> 
> > My investigation into this points to the function
> > gnc:html-acct-table-add-accounts! in

...

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

> 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'll spend some more time trying to narrow it down. There is one part
that references (in the comments) recursing over accounts that aren't
even used.



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

In all honesty, and in due respect to whoever rewrote that part, it
looks like it was written by someone who doesn't know scheme or
functional languages in general. I'll admit that I have next to no
experience except that my earlier years of hacking involved som euse
of funtional languages and they just seem to work for my brain. So
there are lots of things that are done in that function that appear to
my eye to be done very inefficiently. I saw that and sort of assumed
that the rpoblem was the overall achitecture of the function. 

Of course, I could be completely wrong and it could certainly be any
number of other things called from within that function. I'll dig in
some more and see if can can narrow it down to more than just "the
whole function is slow". Though I still believe that to be the
case. :)

thanks Christian, I'll be in touch.

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/20071006/e3cbfe37/attachment.bin