This is the mail archive of the
mailing list for the GDB project.
Re: MI: performance of getting stack arguments
- From: Daniel Jacobowitz <drow at false dot org>
- To: Vladimir Prus <ghost at cs dot msu dot su>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 18 Apr 2006 12:16:54 -0400
- Subject: Re: MI: performance of getting stack arguments
- References: <email@example.com>
On Tue, Apr 18, 2006 at 08:10:34PM +0400, Vladimir Prus wrote:
> I've run into a performance problem with "-stack-list-arguments 1" command.
> I issue the command in order to obtain stack arguments for all frames, and
> I've 129 frames. Each frame has just a couple of arguments. However, the
> command execution takes 608 ms.
> If this command is issued repeatedly, the time is roughly the same.
> 1. Any ideas why the command takes so long?
It's reading a lot of memory, probably. Is it really the arguments,
rather than the backtrace, causing the delay? If it's the arguments,
we may be able to improve it. Maybe build a debuggable GDB and "maint
> 2. Any ideas what should I do to to avoid making user wait half-a-second on
> each "step"? I can try to reload stack only when current frame id changes.
> But then, each time I enter a new function, there's still that
> half-a-second delay.
Probably only some of these are visible; you could just do the visible
ones? Or, eventually, you could do what Xcode does and get stack IDs
from GDB, and assume that arguments haven't changed on step in. I find
that a bit shady though, given how likely it is that their "apparent"
values will change.