Re: MI: performance of getting stack arguments

[Vladimir Prus <ghost@cs.msu.su>]

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