MI: performance of getting stack arguments

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

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!

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

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

 > > 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.n
z/~nickrob

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

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

> From: Nick Roberts <nickrobsnap.net.nz>
> Date: Wed, 19 Apr 2006 09:37:13 +1200
> Cc: Robert Dewar <dewaradacore.com>, 	Vladimir
Prus <ghostcs.msu.su>, gdbsources.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.

 > > 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.n
z/~nickrob

> Cc: Vladimir Prus <ghostcs.msu.su>, gdbsources.redhat.com
> From: Jim Ingham <jinghamapple.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.