From: Jim Ingham <jingham@apple.com>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb@sources.redhat.com
Subject: Re: MI: performance of getting stack arguments
Date: Tue, 18 Apr 2006 19:11:00 -0000 [thread overview]
Message-ID: <1CE7391B-7261-49BD-9068-89C201F555DE@apple.com> (raw)
In-Reply-To: <e2331r$cbr$1@sea.gmane.org>
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
>
>
next prev parent reply other threads:[~2006-04-18 16:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-18 16:40 Vladimir Prus
2006-04-18 16:45 ` Daniel Jacobowitz
2006-04-18 21:15 ` Jim Ingham
2006-04-19 7:55 ` Vladimir Prus
2006-04-19 16:13 ` Eli Zaretskii
2006-04-20 8:50 ` Daniel Jacobowitz
2006-04-26 14:10 ` Vladimir Prus
2006-04-26 14:59 ` Daniel Jacobowitz
2006-04-26 18:02 ` Vladimir Prus
2006-04-26 18:17 ` Daniel Jacobowitz
2006-04-18 19:11 ` Jim Ingham [this message]
2006-04-18 21:35 ` Robert Dewar
2006-04-18 21:37 ` Jim Ingham
2006-04-19 6:08 ` Robert Dewar
2006-04-19 7:30 ` Vladimir Prus
2006-04-19 6:11 ` Nick Roberts
2006-04-19 8:45 ` Eli Zaretskii
2006-04-19 9:02 ` Nick Roberts
2006-04-19 12:40 ` Eli Zaretskii
2006-04-20 10:22 ` Jim Ingham
2006-04-19 6:20 ` Vladimir Prus
2006-04-19 8:28 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1CE7391B-7261-49BD-9068-89C201F555DE@apple.com \
--to=jingham@apple.com \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox