This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: performance of getting stack arguments
On Tuesday 18 April 2006 20:16, Daniel Jacobowitz wrote:
> On Tue, Apr 18, 2006 at 08:10:34PM +0400, Vladimir Prus wrote:
> > Hi,
> > 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?
It's specifically the -stack-list-arguments command that takes 600ms. The
separately issued -stack-list-frames takes 150ms which is not fast either,
but not as bad as -stack-list-arguments.
> If it's the arguments,
> we may be able to improve it. Maybe build a debuggable GDB and "maint
> set profile"?
Sure. What's the right way to build debuggable GDB, setting CFLAGS=-g during
configure or something else?
> > 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?
I though about it and it might work, assuming that "-stack-list-arguments 1
100 110" won't take too much time to get to frame 100. I think getting to
frame 100 should be fast, since nothing should be printed, but will need to
check.
> 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.
Since the primary use of arguments in stack windows (IMO) is to spot
"suspicious" values first time you stop, it might be not necessary to update
arguments at each step. Only after "continue"/stop.
- Volodya