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