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