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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
