Report Engine Speed

Jeff Kletsky gnucash at allycomm.com
Fri Feb 19 20:54:52 EST 2010


On 2/19/2010 12:06 PM, Christian Stimming wrote:
>
> [...] what I can recall is this:
> All the "number collecting calculations" in all of the reports are
> horribly inefficient, or more academic: coded in the wrong level of
> abstraction. That is, the calculation of the balance difference between start
> and end of a reporting period is usually done by obtaining the list of splits
> (transactions) in question from within the scheme code, then summing over all
> of those splits. Also, the intermediate results are not cached at all, even
> during one report generation run, so they are calculated over and over again
> when the report is generated. This turns your O(n) problem into an O(n^2)
> problem.
>    

Thanks for the insight!

It was my first instinct as well was that there was something 
inefficient in the way that the data behind the report was being collected.

Interestingly, crude timing information suggests that the bulk of the 
time is in html-document-render. The renderer in budget.scm (2.2.9, at 
least) is returning in 3.8 wall-clock seconds, but html-document-render 
is taking 13.4 seconds. A quick look at html-object-renderer shows it 
being called 42,019 times in the roughly 12 seconds it takes, with the 
string-append that follows consuming a little over a second. Seems as 
though some structural changes in how the HTML is being generated may 
have some very meaningful improvements!

I'll probably end up taking a stab at an eguile version this weekend.

Jeff






More information about the gnucash-devel mailing list