optimizing reports

[Andrew Sackville-West]

On Sun, Oct 07, 2007 at 08:54:45AM -0400, Dan Widyono wrote:
> As a humble suggestion, it might pay large dividends to invest some time
> researching scheme profiling methods.  This would cover Christian's ideas of
> checking what was really bogging down the report(s), and would help you or
> anyone else "fix" or speed up other reports in the future.  Perhaps folks
> here already know of something.

I spent some time looking into this and came to the conclusion that
for my limited skills itwas more reasonable to just trace the flow of
code (lots of (display "now doing foo") with snapshots of variables)
to try and figure out where it was spending most of its time. I've
pretty much narrowed that down to a couple portions of
html-acct-table-add-accounts!. (does one punctuate after a punctuated
function name? hmmm...)

I saw that thread you've posted and several like it but none that
seemed to come to any real conclusion and there certainly is no switch
that just turns on some kind of profiling (ala bash's set -x or haskell's -p (i think)
compiler flag).

that said, if there is something better than what I'm currently doing,
that'd be great.

> 
> > okay, thanks for this history. I agree (as I think everyone does) that
> > there are some significant performance issues. As far as the
> > layout/html stuff goes, I really don't care, but the performance is a
> > huge factor.
> 
> FWIW, Firefox is pretty nimble for me most of the time.  Except when it comes
> to rendering large tables.  Therefore, layout is intimately tied to
> performance in this one particular extreme case (which happens to be
> not-quite-just-a-corner-case in GnuCash reports).

I don't think there is anything being generated that is large enough
to bog down rendering ni a significant way. And really, once it starts
rendering (at least the current engine) the user sees stuff happening
and that's as good as having the report done at that point. A few
seconds of stuff flashing on the screen while its rendering is okay
IMO. The real issue I'm dealing with is (at least in the income
report) 20-40 seconds of no action on the screen, no response from
gnucash and a pegged cpu. That's bad and I'm still pretty sure that
its a result of just seriously inefficient recursion. 

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/20071007/220569a2/attachment.bin