Re: Guile profiling tools?

[Jim Blandy <jimb@red-bean.com>]

> Harvey Stein was asking why only functions with the trace property
> would be traced. Having spent some time yesterday on the issue
> (substituting experiments for philosophical reasoning) the answer
> seems to be that enabling tracing on *every* apply would yield an
> infinite loop since the trace handler (and surrounding facilities such
> as the repl) would need to do applys also. If this is to work, there
> needs to be some mechanism that would allow the code in the evaluator
> to decide when to trace the apply and when not to. Ideas are welcome.

I haven't thought very carefully about profiling in Guile, so take
this with a grain of salt, but:

It might be appropriate for tracing to be controlled by a variable
which is dynamically bound.  So when invoking code you want to
profile, you bind this variable to #t, telling Guile to profile
function apps.  The evaluator would bind this variable to #f while
calling the tracing handler, so the handler doesn't get profiled
itself.

> We have been developing with snapshot 1990315 and I wanted to update
> to a more recent snapshot (19980804) but our code seems to run much
> slower in the new than in the old (a full minute slower in a 2-3
> minute run).

Hmm.  Let me ask the obvious: have you turned debugging off?  Enabling
debugging slows down the evaluator by a factor of two.

A less obvious idea: if you do a longer run (ten minutes, say), is it
still only a minute slower, or is it still 50% - 33% slower?  If the
module system slowed down, then that would make global variable
references slower, but only the *first* time the variables are
referenced; after that, the variable's value cell is stored directly
in the tree.  Thus, you take a hit the first time you run a piece of
code, but after that it doesn't make a difference.