Re: MI: performance of getting stack arguments

Jim Ingham
2006-04-19T16:13:09Z

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