Profilers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Profilers

Bill Schwab
Hello all,

My experimental stepping profiler "runs" - no promises past that :)

I haven't found a way to wait for the profiled block's value without
deadlocking the profiled process.  Otherwise, it's stopped crashing and
creates nodes for Ian's profile browser.  The nodes might even be correct.
So far, it captures counts but no time information.

Ian, did you use [[aBlock value] value] value] ensure:[...] to align
different branches of the profiled code?  My results typically look worse
when I try to ignore stack frames, with likely explanations including: I'm
not looking at the correct frames; the resulting multiple branches don't
line up correctly.  How did you determine the correct number of frames to
ignore?  I tried computing it from stack frame indexes with less than
satisfying results =:0

Back to times, and with the single interest of making it run (to be followed
by making it correct, etc.), it seemed reasonable to create nodes in the
cloned #populateStackModel - SteppingProfiler is a shotgun wedding of
Profiler and Debugger.

populateStackModel

      | theTopFrame size |

   theTopFrame := process topFrame.
   size := ( process stackDepthFrom:theTopFrame ) - self framesToIgnore.
   size > 0 ifTrue:[
      sampleSet
         addSample:( process stackFramesFrom:theTopFrame depth:size )
            elapsedTime:1;
            yourself.
   ].

Any thoughts on which clock to use to get times, and whether it makes sense
to collect them this way (assuming an iv would store the time of the last
recorded sample, or something along those lines) would be appreciated.

Have a good one,

Bill

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


Reply | Threaded
Open this post in threaded view
|

Re: Profilers

Chris Uppal-3
Bill,

> Ian, did you use [[aBlock value] value] value] ensure:[...] to align
> different branches of the profiled code?

I'm probably responsible for that particular passage of code, and I must admit
that it was pure Voodoo programming.  I was experimenting with the stack frame
calculation, and the number of ignored frames that *should* (I thought) have
made the entry-point evaluation invsible, er, didn't.  So, being the top-flight
professional programmer that I am, I simply added nested evaluations until it
came out right at the time.  Shameful isn't it ?

Since then Ian may have revisited this, and found a proper justification for
the number of nested #values, but I suspect not, since the Voodoo seems to have
stopped working for recent versions of Dolphin...:-(

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Profilers

Ian Bartholomew-14
Chris/Bill,

> Since then Ian may have revisited this, and found a proper justification
> for the number of nested #values,

Nah. It was working so I tiptoed very carefully around it, and anything else
in there that I couldn't remember the reason for :).  I had a quick look
when Bill first mentioned it and thought that the #values were just to
ensure that the code answered the same result when it was wrapped inside the
Profiler evaluation as it did when it ran normally.  I shall have to
investigate further.

>                but I suspect not, since the Voodoo seems to have
> stopped working for recent versions of Dolphin...:-(

Which bit isn't working now?.  To make the samples ignore the profiling code
I had to adjust the number of frames skipped (further up in the method Bill
mentions) from 4 to 5 for Dolphin 5 but apart from that it seems to be
correct.  The only problem with the package currently on the web site is an
error in the disassembly listing, caused by a change in the way Dolphin
creates the list.

One other thing I've changed in this area, as a result of a suggestion, is
to make the tree display the selector that is being evaluated rather than
the method containing the selector that is being evaluated.  I think it
makes the profiling tree easier to read but does mean that the node at the
very top isn't displayed.

Ian


Reply | Threaded
Open this post in threaded view
|

Re: Profilers

Bill Schwab-2
In reply to this post by Chris Uppal-3
Chris,

> I'm probably responsible for that particular passage of code, and I must
admit
> that it was pure Voodoo programming.  I was experimenting with the stack
frame
> calculation, and the number of ignored frames that *should* (I thought)
have
> made the entry-point evaluation invsible, er, didn't.  So, being the
top-flight
> professional programmer that I am, I simply added nested evaluations until
it
> came out right at the time.  Shameful isn't it ?

Not compared to the way I replicated (I hope!) the debugger's handling of
the VM events :)

Have a good one,

Bill

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


Reply | Threaded
Open this post in threaded view
|

Re: Profilers

Chris Uppal-3
In reply to this post by Ian Bartholomew-14
Ian,

I've only just noticed this (I seem to have skipped a couple of days in
switching ISPs).

> >                but I suspect not, since the Voodoo seems to have
> > stopped working for recent versions of Dolphin...:-(
>
> Which bit isn't working now?.  To make the samples ignore the profiling code
> I had to adjust the number of frames skipped (further up in the method Bill
> mentions) from 4 to 5 for Dolphin 5 but apart from that it seems to be
> correct.

The only problem is that the evaluation is showing on the stack, but that's
probably because I'm still using the D4 version.

Been meaning to pull down the newest version(s) for some time...

> Ian

    -- chris