Re: [PATCH] -stack-select-frame

[Jason Molenda <jmolenda at apple dot com>]

On Jun 17, 2005, at 12:24 AM, Nick Roberts wrote:

> > (one of the parts of this profiling which is especially useful is
> > that we have a "mi-timings-enabled" setting.  When it's enabled,
> > every MI command reports how long gdb took to complete it, e.g. the
> > "time=" bit at the end here:
> >
> > -> 50-stack-list-frames 0 5
> > <- 50^done,stack=[frame=
> > {level="0",addr="0x0009e7fc",fp="0xbfffe700",func=" [...] ,frame=
> > {level="5",addr="0x936265d0",fp="0xbfffeee0",func="-[NSApplication
> > run]"}],time=
> > {wallclock="0.14353",user="0.00584",system="0.00335",start="111895234 
> > 8.0
> > 03847",end="1118952348.147372"}
>
> Yes but what happens when the stack is much deeper, 20 or 30 say,  
> like it can
> be when you you are debugging Emacs, or GDB for that matter?


Yes, stack crawling is slow, and stacks 30-50 frames deep are not at  
all unusual in GUI heavy-call-back applications like we have on MacOS  
X.  When we've worked on optimizing performance on something like a  
user pressing the "Next" button, -stack-list-frames is a serious  
problem.

We implemented a command, "-stack-list-frames-lite" here at Apple.   
It crawls the stack (there's a -limit option to specify how many  
frames to crawl) and shows the pc + fp for each frame.  A "stop at a  
breakpoint and press next a few times" scenario looks like

-thread-list-ids
-stack-list-frames-lite -limit 500
-stack-list-frames 0 7  (I had eight frames at this point)
-stack-select-frame 0
-stack-list-arguments 2 0 0
-stack-list-locals 2 1
-file-list-statics -file "*CURRENT FRAME*" -shlib "" "--no-values" - 
filter "^_OBJC" -constants 0
-exec-next

-thread-list-ids
-stack-list-frames-lite -limit 500
-stack-select-frame 0
-stack-list-frames 0 0
-var-update "var1" "var2" "var3"
-exec-next

and so on.  So we only do the (expensive) -stack-list-frames the  
first time we enter a function.

But the point I originally was trying to make is that the overhead of  
issuing MI commands is really, really, really low on MacOS X.  For  
instance, -stack-list-frames 0 0 took 0.00039 seconds wallclock to  
return its information in a quick test I just did.  -stack-list- 
frames-lite with 8 frames took 0.01422 seconds.  -var-update with  
three varobjs took 0.00493 seconds.

Yeah, I happen to be using a really fast G5 system right now, but we  
do all of our performance timings on slower boxes (currently around  
the 1GHz range) and my own personal goal is to keep the time it takes  
for a "Next" button press to finish should be no more than 0.2  
seconds, and it should be a *reliable* amount of time.  Users get  
into a rhythm of pressing "Next" and if it takes much longer than 0.2  
seconds, or if it takes different amounts of time, they get grumpy.

Oops, I'm off topic again.  MI commands fast.  It's not going to  
cause me any problems if you add more output to existing commands,  
but we've seen little benefit in trying to combine discrete commands  
here at Apple.

J