Note from Eli below. I guess I didn't look at the PLT profiler
recently, and I'll add it to my todo list. Then I'll think about it
some more. :-)
Thanks Eli for the note.
Aziz,,,
Begin forwarded message:
From: Eli Barzilay <[email protected]>
Date: September 20, 2009 5:19:39 AM GMT+03:00
To: Abdulaziz Ghuloum <[email protected]>
Subject: Re: Profiler?
Abdulaziz Ghuloum wrote:
That's certainly true. Another concern is whether the results of
the profiled code match what you get without profiling under the
same implementation. This is what makes me queasy about doing
anything regarding profiling in Ikarus.
FWIW, you might have seen DrScheme's profiler, which was implemented
by instrumenting code. It does preserve tail calls, but it can
(and probably does) interfere with inlining etc.
But somewhat recently (in the past ~6 months) we added a new profiler
that I implemented. The idea is to run a thread that periodically
takes a stack snapshot (which is available in mzscheme via
`continuation-mark-set->context') -- collect these things, and at the
end of the run analyze the results. It's basically the same idea as
the profiler in Allegro Lisp (which is what I have experience with) or
gprof (which I looked at and saw that it was similar). Besides being
very light-weight, the fact that it's doing its work on a thread makes
it even less likely to change the runtime behavior -- because the
timings that are sampled are based on per-thread timing, so even if
the sampler takes more time it's not part of the overall numbers.
The code is split nicely into one module that does the sampling
(obviously very plt-specific) and another one that does the analysis.
So if you have a way to grab a stack snapshot, then the rest might be
useful.
(Feel free to forward this, I was just too lazy to find out the
mailing list address.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli
Barzilay:
http://barzilay.org/ Maze is
Life!
