Re: MI: performance of getting stack arguments

[Daniel Jacobowitz <drow@false.org>]

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