optimizing reports

Dan Widyono dan at widyono.net
Sun Oct 7 08:54:45 EDT 2007

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.

Google popped this up in a brief perusal just now:

> Is there any Scheme code profiler that works with Guile?
> It seems Guile's core (libguile/eval.c) has no such code in it.
> Is it a good idea to work on this?  (I guess the debug evaluator
> may have such facilities...)

This is actually fairly easy.  Even the patch below gives some
useful information:

  % guile
  guile> (set! *profile-all* #t)
  guile> (use-modules (oop goops))
  guile> (load "profile.scm")

This post included a short patch to guile source.  This is just an example, I
don't think it will really work (based on comments in follow-ups to that
post), but hopefully things have improved since 2000 when that post was made.

Dan W.

> 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).

More information about the gnucash-devel mailing list