Re: MI: performance of getting stack arguments

[Jim Ingham <jingham@apple.com>]

On Apr 19, 2006, at 1:45 AM, Eli Zaretskii wrote:

>> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
>> From: Jim Ingham <jingham@apple.com>
>> Date: Tue, 18 Apr 2006 14:17:24 -0700
>>
>> But just keep in
>> mind, when you are implementing a GUI debugger that anything you show
>> in the UI you are pledging to update every time a step is completed.
>> And most folks are pretty sensitive about how long it takes for each
>> step to complete. So you do need to be a bit conservative about what
>> you display by default.  Adding to this, gdb does get slow as
>> programs get large, which makes it even more important to be  
>> judicious.
>
> How about if we implement a facility to send just the changes in the
> call stack since the last time the stack was sent?  This way, the
> amount of stuff sent each stop will be much smaller, I think.


We have seldom found that it's the amount of data sent that is the  
bottle-neck.  It's almost always gdb's processing that's too slow.

For instance, in the case of the stack, we implemented a "stack-list- 
frames-lite" that uses gdb's unwinder to get the first couple of  
stack frames (which are the hard ones) and then uses a simple method  
that doesn't do unwinding, but just traces the stored pc & fp up the  
stack (which is easy because you know that there are no frameless  
functions in the way.)  Using this (and then only letting gdb do the  
real stack backtrace when the stack has changed) made a noticeable  
improvement in step response times.

Anyway, in the course of profiling all this stuff, we didn't find  
that the data handing was a significant part of the time spent.

N.B. one of the points of Andrew's frame changes was to allow the  
platform unwinders to have a quick unwind if only the fp & pc were  
requested, and then do the full unwind if anything else was  
requested.  That way just the simple stack would be fast, and  
anything more would bring in prologue parsing, etc.  It's been on my  
to-do list to try to get this to work for a while, but I haven't  
found the time to do it yet.

Jim