MI: performance of getting stack arguments

MI: performance of getting stack arguments

[Vladimir Prus]

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?

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. 

Incidentally, it seems that Eclipse does no show arguments in stack view at
all, but that does not seem the right solution.

- Volodya

Re: MI: performance of getting stack arguments

[Daniel Jacobowitz]

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

Re: MI: performance of getting stack arguments

[Jim Ingham]

Do you really have a UI that shows the stack arguments for ALL the  
frames on the stack?  That's very unusual (and visually a bit  
overwhelming, I would imagine).  The usual stack display shows the  
stack with just the function names.  Then clicking on any given stack  
will populate the arguments for that frame, fill the source window  
with the source for that frame, etc...  This way, you only need to  
fetch the arguments for the bottom-most frame on the stack when you  
stop stepping.  You would only fetch the other stack arguments if the  
user specifically requests them.

For most purposes, when you are stepping through a function you don't  
really care what the arguments higher up on the stack are, and even  
if you want to see them once you rarely need to see if they are  
changing after each step.  Having them always visible sounds like it  
would make the UI very noisy.  Fetching them without displaying them  
is a waste of time, since you can fetch them one by one on demand.

Jim

On Apr 18, 2006, at 9:10 AM, 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?
>
> 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.
>
> Incidentally, it seems that Eclipse does no show arguments in stack  
> view at
> all, but that does not seem the right solution.
>
> - Volodya
>
>

Re: MI: performance of getting stack arguments

[Jim Ingham]

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

Re: MI: performance of getting stack arguments

[Robert Dewar]

Jim Ingham wrote:
> Do you really have a UI that shows the stack arguments for ALL the 
> frames on the stack?  That's very unusual (and visually a bit 
> overwhelming, I would imagine).  The usual stack display shows the stack 
> with just the function names.  Then clicking on any given stack will 
> populate the arguments for that frame, fill the source window with the 
> source for that frame, etc...  This way, you only need to fetch the 
> arguments for the bottom-most frame on the stack when you stop 
> stepping.  You would only fetch the other stack arguments if the user 
> specifically requests them.

The ordinary bt from gdb gives this info, and it would be a pain
not to have it!

Re: MI: performance of getting stack arguments

[Jim Ingham]

On Apr 18, 2006, at 12:11 PM, Robert Dewar wrote:

> Jim Ingham wrote:
>> Do you really have a UI that shows the stack arguments for ALL the  
>> frames on the stack?  That's very unusual (and visually a bit  
>> overwhelming, I would imagine).  The usual stack display shows the  
>> stack with just the function names.  Then clicking on any given  
>> stack will populate the arguments for that frame, fill the source  
>> window with the source for that frame, etc...  This way, you only  
>> need to fetch the arguments for the bottom-most frame on the stack  
>> when you stop stepping.  You would only fetch the other stack  
>> arguments if the user specifically requests them.
>
> The ordinary bt from gdb gives this info, and it would be a pain
> not to have it!
>

I dunno.  I find that having a really simple clean stack listing with  
just function names makes it much easier to tell where I am in the  
program.  Most of the time that's what I want to see, not what the  
third argument to the function 10 frames up on the stack was.  If I  
want that, I don't find it a problem to dial it up.  And in the GUI  
all you have to do is click on the frame to see the source &  
arguments.  This seems to work pretty well for folks, at least we get  
lots of suggestions from our users, but nobody's ever asked us to  
change this.

Anyway, this is a "to each his own" kind of thing.  But just keep in  
mind, when you are implementing a GUI debugger that anything you show  
in the UI you are pledging to update every time a step is completed.   
And most folks are pretty sensitive about how long it takes for each  
step to complete. So you do need to be a bit conservative about what  
you display by default.  Adding to this, gdb does get slow as  
programs get large, which makes it even more important to be judicious.

Also, in a GUI much more stuff is visible at once, so if each element  
is too complex then the overall result is noisy and hard to use.  
Visual Studio used by default to show a whole bunch of junk in the  
stack window (pc, args, etc.) and way back when I used it I found it  
really hard to look at for just this reason.  According to the 2005  
Online docs, you can turn all the other info off and display just the  
function name if you want...

Jim

Re: MI: performance of getting stack arguments

[Robert Dewar]

Jim Ingham wrote:
> 
> 
> 
> On Apr 18, 2006, at 12:11 PM, Robert Dewar wrote:
> 
>> Jim Ingham wrote:
>>> Do you really have a UI that shows the stack arguments for ALL the 
>>> frames on the stack?  That's very unusual (and visually a bit 
>>> overwhelming, I would imagine).  The usual stack display shows the 
>>> stack with just the function names.  Then clicking on any given stack 
>>> will populate the arguments for that frame, fill the source window 
>>> with the source for that frame, etc...  This way, you only need to 
>>> fetch the arguments for the bottom-most frame on the stack when you 
>>> stop stepping.  You would only fetch the other stack arguments if the 
>>> user specifically requests them.
>>
>> The ordinary bt from gdb gives this info, and it would be a pain
>> not to have it!
>>
> 
> I dunno.  I find that having a really simple clean stack listing with 
> just function names makes it much easier to tell where I am in the 
> program.  Most of the time that's what I want to see, not what the third 
> argument to the function 10 frames up on the stack was.  If I want that, 
> I don't find it a problem to dial it up.  And in the GUI all you have to 
> do is click on the frame to see the source & arguments.  This seems to 
> work pretty well for folks, at least we get lots of suggestions from our 
> users, but nobody's ever asked us to change this.

Gosh I would find this horrible. For example, a very common thing for
me is to debug a crash in the gigi section of GNAT. I need to quickly
loook down the call stack to find the most recent reference to a
routine with a parameter gnat_node to find the corresponding node
in the front end tree. It would be very painful to iterate frame
by frame to find this.
> 
> Anyway, this is a "to each his own" kind of thing.  But just keep in 
> mind, when you are implementing a GUI debugger that anything you show in 
> the UI you are pledging to update every time a step is completed.  And 
> most folks are pretty sensitive about how long it takes for each step to 
> complete. So you do need to be a bit conservative about what you display 
> by default.  Adding to this, gdb does get slow as programs get large, 
> which makes it even more important to be judicious.

Yes, well I agree the GUI requirements are quite different indeed.
I only want to see the call stack when I need it and not all the
time (I don't use a GUI interface to GDB, I prefer to use it in
command line mode).
> 
> Also, in a GUI much more stuff is visible at once, so if each element is 
> too complex then the overall result is noisy and hard to use. Visual 
> Studio used by default to show a whole bunch of junk in the stack window 
> (pc, args, etc.) and way back when I used it I found it really hard to 
> look at for just this reason.  According to the 2005 Online docs, you 
> can turn all the other info off and display just the function name if 
> you want...

Seems reasonable to have a much more streamlined call stack visible all
the time, and a special command to decorate it with parameter values.
> 
> Jim

Re: MI: performance of getting stack arguments

[Nick Roberts]

 > > The ordinary bt from gdb gives this info, and it would be a pain
 > > not to have it!
 > >
 > 
 > I dunno.  I find that having a really simple clean stack listing with  
 > just function names makes it much easier to tell where I am in the  
 > program.

I agree.  The requirements are different: with CLI the user will generally type
bt at a specific point in the session, while with MI the command
"-stack-list-frames" gets sent every time the UI needs to update.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: performance of getting stack arguments

[Vladimir Prus]

On Tuesday 18 April 2006 20:41, Jim Ingham wrote:
> Do you really have a UI that shows the stack arguments for ALL the
> frames on the stack?  That's very unusual (and visually a bit
> overwhelming, I would imagine).  

That's what I have at the moment. It basically worked that way before and I 
wanted to preserve existing behaviour.

There's in fact one use case where I want full stacktrace. When I'm debugging 
a crash in console gdb, output of "bt" with arguments can be usefull, because 
I can immediately spot if 10 levels up the stack some parameter has 
suspicious value.

> The usual stack display shows the 
> stack with just the function names.  Then clicking on any given stack
> will populate the arguments for that frame, fill the source window
> with the source for that frame, etc...  This way, you only need to
> fetch the arguments for the bottom-most frame on the stack when you
> stop stepping.  You would only fetch the other stack arguments if the
> user specifically requests them.

That would work, and require just ~100ms to get the entire stack without 
arguments. I'm still thinking that a separate command to show all arguments 
is necessary.

> For most purposes, when you are stepping through a function you don't
> really care what the arguments higher up on the stack are, and even
> if you want to see them once you rarely need to see if they are
> changing after each step.  Having them always visible sounds like it
> would make the UI very noisy.  Fetching them without displaying them
> is a waste of time, since you can fetch them one by one on demand.

It's possible to fetch arguments only when stack widget is visible, but I 
suspect users will keep it visible all the time.

Concerning other data points: Visual Studio 2005 shows argument values by 
default, but allows to hide them. Eclipse does not show them and it's not 
configurable. CBuilderX shows arguments values. However, it first shows 
current line and then fetches arguments values, and I don't have to wait for
stack view to update before next step.

Guess there's still something to think about.

- Volodya





>
> Jim
>
> On Apr 18, 2006, at 9:10 AM, 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?
> >
> > 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.
> >
> > Incidentally, it seems that Eclipse does no show arguments in stack
> > view at
> > all, but that does not seem the right solution.
> >
> > - Volodya

Re: MI: performance of getting stack arguments

[Vladimir Prus]

On Wednesday 19 April 2006 01:35, Robert Dewar wrote:

> > Also, in a GUI much more stuff is visible at once, so if each element is
> > too complex then the overall result is noisy and hard to use. Visual
> > Studio used by default to show a whole bunch of junk in the stack window
> > (pc, args, etc.) and way back when I used it I found it really hard to
> > look at for just this reason.  According to the 2005 Online docs, you
> > can turn all the other info off and display just the function name if
> > you want...
>
> Seems reasonable to have a much more streamlined call stack visible all
> the time, and a special command to decorate it with parameter values.

Good idea! I'll think about it.

Thanks,
Volodya

Re: MI: performance of getting stack arguments

[Vladimir Prus]

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

Re: MI: performance of getting stack arguments

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Tue, 18 Apr 2006 20:10:34 +0400
> 
> 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.

That's an awful lot, I think.  When I debug Emacs, there are sometimes
many _thousands_ of frames on the call stack (during GC, for example).

> If this command is issued repeatedly, the time is roughly the same. 
> 
> 1. Any ideas why the command takes so long?

GDB has a facility to profile itself (see "maint set profile").
Perhaps you could use that to find out where is the time sink.

Re: MI: performance of getting stack arguments

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 19 Apr 2006 09:37:13 +1200
> Cc: Robert Dewar <dewar@adacore.com>, 	Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> I agree.  The requirements are different: with CLI the user will generally type
> bt at a specific point in the session, while with MI the command
> "-stack-list-frames" gets sent every time the UI needs to update.

These are not _requirements_, these are _use_cases_.  The requirements
are the same: to be fast enough for most uses.  E.g., nothing prevents
me from including "bt" in the commands list of a breakpoint, which
would force GDB to produce the backtrace on each stop.

Re: MI: performance of getting stack arguments

[Nick Roberts]

 > > I agree.  The requirements are different: with CLI the user will generally
 > > type bt at a specific point in the session, while with MI the command
 > > "-stack-list-frames" gets sent every time the UI needs to update.
 > 
 > These are not _requirements_, these are _use_cases_.  The requirements
 > are the same: to be fast enough for most uses.  E.g., nothing prevents
 > me from including "bt" in the commands list of a breakpoint, which
 > would force GDB to produce the backtrace on each stop.

Whatever you want to call them I think, in practice, such commands will
generally be issued more frequently with a UI than from the command line.
Improving the response time can be tackled at two ends of course: not only
making the command run more quickly but also running it less frequently.  For
example, using event notification to tell the UI when the current frame has
changed.  Currently for Emacs I request a new stack after each user command,
which is clearly inefficient.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: performance of getting stack arguments

[Eli Zaretskii]

> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> From: Jim Ingham <jingham@apple.com>
> Date: Tue, 18 Apr 2006 14:17:24 -0700
> 
> But just keep in  
> mind, when you are implementing a GUI debugger that anything you show  
> in the UI you are pledging to update every time a step is completed.   
> And most folks are pretty sensitive about how long it takes for each  
> step to complete. So you do need to be a bit conservative about what  
> you display by default.  Adding to this, gdb does get slow as  
> programs get large, which makes it even more important to be judicious.

How about if we implement a facility to send just the changes in the
call stack since the last time the stack was sent?  This way, the
amount of stuff sent each stop will be much smaller, I think.

Re: MI: performance of getting stack arguments

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Wed, 19 Apr 2006 10:20:07 +0400
> Cc: gdb@sources.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...

Re: MI: performance of getting stack arguments

[Daniel Jacobowitz]

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

Re: MI: performance of getting stack arguments

[Jim Ingham]

On Apr 19, 2006, at 1:45 AM, Eli Zaretskii wrote:

>> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
>> From: Jim Ingham <jingham@apple.com>
>> Date: Tue, 18 Apr 2006 14:17:24 -0700
>>
>> But just keep in
>> mind, when you are implementing a GUI debugger that anything you show
>> in the UI you are pledging to update every time a step is completed.
>> And most folks are pretty sensitive about how long it takes for each
>> step to complete. So you do need to be a bit conservative about what
>> you display by default.  Adding to this, gdb does get slow as
>> programs get large, which makes it even more important to be  
>> judicious.
>
> How about if we implement a facility to send just the changes in the
> call stack since the last time the stack was sent?  This way, the
> amount of stuff sent each stop will be much smaller, I think.


We have seldom found that it's the amount of data sent that is the  
bottle-neck.  It's almost always gdb's processing that's too slow.

For instance, in the case of the stack, we implemented a "stack-list- 
frames-lite" that uses gdb's unwinder to get the first couple of  
stack frames (which are the hard ones) and then uses a simple method  
that doesn't do unwinding, but just traces the stored pc & fp up the  
stack (which is easy because you know that there are no frameless  
functions in the way.)  Using this (and then only letting gdb do the  
real stack backtrace when the stack has changed) made a noticeable  
improvement in step response times.

Anyway, in the course of profiling all this stuff, we didn't find  
that the data handing was a significant part of the time spent.

N.B. one of the points of Andrew's frame changes was to allow the  
platform unwinders to have a quick unwind if only the fp & pc were  
requested, and then do the full unwind if anything else was  
requested.  That way just the simple stack would be fast, and  
anything more would bring in prologue parsing, etc.  It's been on my  
to-do list to try to get this to work for a while, but I haven't  
found the time to do it yet.

Jim

Re: MI: performance of getting stack arguments

[Vladimir Prus]

Daniel Jacobowitz wrote:

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

Ok, I'll try to do this. First on -stack-list-arguments, since it's pretty
slow to. But, maybe I should be using callgrind (part of valgrind suite)
for profiling?

- Volodya

Re: MI: performance of getting stack arguments

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 06:06:26PM +0400, Vladimir Prus wrote:
> Ok, I'll try to do this. First on -stack-list-arguments, since it's pretty
> slow to. But, maybe I should be using callgrind (part of valgrind suite)
> for profiling?

I've had a lot of trouble getting the valgrind tools to play nice with
GDB; they want to debug the children too and get confused by ptrace.
But it looks like there've been some changes and now the default is not
to do that, so maybe it'll work better.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: performance of getting stack arguments

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Wed, Apr 26, 2006 at 06:06:26PM +0400, Vladimir Prus wrote:
>> Ok, I'll try to do this. First on -stack-list-arguments, since it's
>> pretty slow to. But, maybe I should be using callgrind (part of valgrind
>> suite) for profiling?
> 
> I've had a lot of trouble getting the valgrind tools to play nice with
> GDB; they want to debug the children too and get confused by ptrace.
> But it looks like there've been some changes and now the default is not
> to do that, so maybe it'll work better.

Ok. I'll try.

Here's the results I get for multiple -stack-list-frames commands:

 %   cumulative   self              self     total
 time   seconds   seconds    calls  Ts/call  Ts/call  name
 24.18      2.50     2.50                             find_pc_sect_psymbol
 18.28      4.39     1.89                            
lookup_minimal_symbol_by_pc_section
  8.03      5.22     0.83                             find_pc_sect_psymtab
  6.48      5.89     0.67                             find_pc_sect_section
  4.06      6.31     0.42                             dwarf2_frame_find_fde
  3.09      6.63     0.32                             find_pc_sect_line
  2.03      6.84     0.21                             mem_file_write
  1.84      7.03     0.19                             printchar

I'm not sure how to interpret this data, though.

- Volodya

Re: MI: performance of getting stack arguments

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 06:53:43PM +0400, Vladimir Prus wrote:
> Here's the results I get for multiple -stack-list-frames commands:
> 
>  %   cumulative   self              self     total
>  time   seconds   seconds    calls  Ts/call  Ts/call  name
>  24.18      2.50     2.50                             find_pc_sect_psymbol
>  18.28      4.39     1.89                            
> lookup_minimal_symbol_by_pc_section
>   8.03      5.22     0.83                             find_pc_sect_psymtab
>   6.48      5.89     0.67                             find_pc_sect_section
>   4.06      6.31     0.42                             dwarf2_frame_find_fde
>   3.09      6.63     0.32                             find_pc_sect_line
>   2.03      6.84     0.21                             mem_file_write
>   1.84      7.03     0.19                             printchar
> 
> I'm not sure how to interpret this data, though.

I'd definitely try to get a callgraph - either from --enable-profiling
or callgrind, whatever.  It looks like we're doing a _lot_ of
unwinding; otherwise dwarf2_frame_find_fde shouldn't be showing up.

-- 
Daniel Jacobowitz
CodeSourcery