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] |
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 |
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 |
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] |
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 |
Free forum by Nabble | Edit this page |