This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: performance of getting stack arguments

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

Cc: Vladimir Prus <>,
From: Jim Ingham <>
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]