Re: [PATCH] -stack-select-frame

[Nick Roberts <nickrob@snap.net.nz>]

[Jason - Sorry if you get this twice.  My first message bounced at RedHat, for
some reason.]

 > > I thought it would save some time if the user doesn't need to see the
 > > whole stack.
 > 
 > FWIW we've done a lot of careful timing analysis, and the back &  
 > forth communication between our GUI and gdb is so fast as to be  
 > pointless to optimize.  We original considered adding special purpose  
 > "give Xcode everything it needs to know at a breakpoint hit" type  
 > commands but when we saw how fast the majority of MI commands can  
 > execute & be parsed by the GUI, it was obvious that this was not a  
 > useful area to optimize.  And frankly, in my anecdotal experience,  
 > MacOS X isn't the fastest OS at things like "two processes talking  
 > over a pipe".

You've clearly been more quantitative.  With my limited resources, I'm
just guessing what might work best.  I've suggested to Daniel a change
that, I hope, won't impact on Xcode.  I think you have your own copy
of GDB and, like you say, you don't really care, but I guess its best
not to diverge more than necessary.

 > (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="1118952348.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?

Nick