[PATCH] -stack-select-frame
Jason Molenda
jmolenda@apple.com
Fri Jun 17 19:48:00 GMT 2005
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
More information about the Gdb-patches
mailing list