Re: MI: performance of getting stack arguments

Daniel Jacobowitz
2006-04-19T12:40:41Z

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
> check.

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).

--
Daniel Jacobowitz
CodeSourcery