Re: Scheme profiling

[Keisuke Nishida]

Hello, Eric.  I'm replying to the list.

Eric Enderton <address@hidden> writes:

> i am attempting to optimize a client's Scheme code.  i
> read your msgs about this on the Guile mailing list. 
> Keisuke, i took your profiling patch (July 15th
> message) and got a version of it working (thank
> you!).   Harvey, i looked at your Scheme-level
> profiler (16 Aug 1998) but i haven't tried it yet.
> 
> i just wanted to ask, has anyone developed this
> further?

I haven't.  I tried to implement another profiler that uses
apply-frame-handler etc., as Mikael said, but it turned out
that the handlers do not bring sufficient information.  (Or
maybe I just couldn't find how to do.  I attached a profiling
data to a procedure when apply-frame-handler was called, and
tried to obtain the data in exit-frame-handler, but I couldn't
figure out from what procedure the process is exiting.)

I'm going to add better profiling support to my VM.  It has
call-hook, which is called when a procedure is called, and
return-hook, which is called when a procedure is returning.
It is easy to add a profiler already.

> some ideas i'm pondering:  my os meter shows mostly
> system time being spent; i assume that is because of
> scm_get_internal_run_time() and so on (i'm on SGI
> IRIX); so i am considering keeping a user-space time
> variable, and updating it via interrupts.  there are
> probably other ways to reduce the profiler overhead. 
> i am also considering trying to add "inclusive" vs
> "exclusive" times, perhaps with call graph
> information. 
> 
> i also considered writing an interrupt-driven
> profiler, where each interrupt checks the top of the
> interpreter's call stack (or the whole stack...). 
> since Lisp-like languages switch functions so often --
> much more often than the granularity of
> scm_get_internal_run_time on my system -- i am
> wondering whether the current approach might have
> "aliasing" artifacts.  my client is not using
> multi-threading, so that makes it easier.  and in a
> perfect world, such a profile could be portable to
> other interpreted languages as well.  but i am still
> hoping to get away with less work than this :).

Yes, I want to measure more precise time, too.  How could
I do that?  What is an interrupt-driven profiler?

> ps. Keisuke, how is your byte-code-compiled Guile
> coming along?  it will be very interesting to see how
> its speed compares.  you probably know this already,
> but Python is byte-code-compiled, and free, if you
> want an example implementation to look at.

It's generally about 10 times as fast as the current Guile,
if properly optimized.  I want to finish some major tasks
in this winter..