This is the mail archive of the
mailing list for the GDB project.
Re: MI: performance of getting stack arguments
On Wed, Apr 19, 2006 at 10:20:07AM +0400, Vladimir Prus wrote:
> 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.
OK, there is probably something absurdly stupid going on then.
> > 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?
Two ways. You can use --enable-profiling as Eli suggested, which will
let you get callgraphs, or you can just use a binary built with the
default CFLAGS (-O2 -g), and "maint set profile". You have to use
gprof --no-graph on the output file to get output if you do that. I
still find it useful - e.g. the numbers I posted to dmi-discuss
yesterday came from that. Its advantage is that it doesn't inflate
small functions as badly.
> 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
It should be instant. That'll just walk the cached list of frames - as
long as nothing is invalidating the frame cache! (One of the more
likely stupid things to be happening).