MI: performance of getting stack arguments

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?  If it's the
arguments,
we may be able to improve it.  Maybe build a debuggable GDB
and "maint
set profile"?

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

-- 
Daniel Jacobowitz
CodeSourcery

On Apr 18, 2006, at 9:16 AM, Daniel Jacobowitz wrote:

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

The way we do it, we only show the function names in the
stack  
display, and the arguments & locals of the bottom-most
frame in a  
detail view.  If the user wants to see the args/locals for
another  
frame, she can click on it, and we fetch the values afresh. 
So we  
always present the correct values.  Nothing shady about this
at all.

It would be more complex if you were presenting the
arguments at all  
times, but I think that would end up being visually very
noisy.   
Anyway, we've never had anybody request this.

Jim

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

> From: Vladimir Prus <ghostcs.msu.su>
> Date: Wed, 19 Apr 2006 10:20:07 +0400
> Cc: gdbsources.redhat.com
> 
> > 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?

You need to configure with --enable-profiling, and then
build as
usual.  (This is explained in the manual, right next to
where "maint
set profile" is described.)  Of course, don't strip
the GDB binary, or
the profiles will be very dull...

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