Profilers

Blair, Ian,

I noticed <debugEventHandler> and thought of Ian's observation that 1
millisecond is getting to be a long time on current hardware.  Would it be
reasonable to base a profiler on a minimal and non-visual debugger that
steps into every message send of a block?

Borrowing (well, stealing shamelessly is more the truth<g>) from Profiler
and Debugger, I got something that looks like it wants to work, but,
doesn't.  It attempts to do what an animating debugger does; if that once
works, then hopefully one could siphon off suitable nodes for Ian's existing
profiler.  Of course, it would be nice if it could profile a block w/o
crashing the system :(  A good guess is that I'm not managing the
asynchronous events properly, and/or not responding correctly to the events
from the VM.

I created a new subclass of Object called SteppingProfiler, and copied code
from Profiler; if it ends up working and being useful, there probably should
be some refactoring to between it and Profiler to avoid the duplication.
There is also quite a bit of stealing from Debugger, but, that's probably to
be expected.

Blair, one thing that occurs to me (this is one of those "it doesn't hurt to
ask" kinds of ideas<g>) is a PluggableDebugger, or whatever else you might
want to call it.  It would basically know how to attach itself to a Process,
handle events correctly, and evaluate blocks with appropriate stack frame
arguments. Is that something that you could create easily and would be
willing to include in the base system?

Ian, one thing that I don't understand about your profiler is the "ignoring"
of lines.  Is the idea to prevent the profiler's profiling itself, or is it
something else?

Another thing that *might* be troublesome is elapsed time.  All of the
stepping might slow things down to the point that such times would be
inflated but still useful, or we might end up with a large number of zeros.
Then there would be the question of how/where to measure the times.

Any comments/suggestions?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

>  Ian, one thing that I don't understand about your profiler is the
> "ignoring" of lines.  Is the idea to prevent the profiler's profiling
> itself, or is it something else?

It takes a few message sends to get from the interrupt event to the
Profiling code and as you don't really want to add them to the profiling
information they are just ignored on the message stack.

The first version of the Dolphin5 goodies I uploaded has some problems in
this area, IIRC it only ignored 4 slots and for D5 it should now ignore 5.
The latest update to the web site cures this problem.

> Any comments/suggestions?

You can use the debuggers "single step" feature (maybe that's the part of
the debugger code you mentioned?)  to achieve something similar.  It takes a
bit (IIRC, a lot) of fiddling - you have to prevent the Debugger trying to
update it's view or it gets _very_ slow - but I have used this in the past
to fully trace short execution paths.

Sounds like it might be a good idea though and might get around the 1mS
problem with the Profiler.

Regards
    Ian