[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scheme profiling
Re: Scheme profiling
22 Sep 2000 07:22:09 -0400
T-gnus/6.14.4 (based on Gnus v5.8.6) (revision 02) SEMI/1.13.7 (Awazu) Chao/1.14.0 (Momoyama) Emacs/20.7 (i686-pc-linux-gnu) MULE/4.1 (AOI)
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
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
> 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..
- Re: Scheme profiling,
Keisuke Nishida <=