Re: MI: performance of getting stack arguments

[Jim Ingham <jingham at apple dot com>]

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