From: Vladimir Prus <ghost@cs.msu.su>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb@sources.redhat.com
Subject: Re: MI: performance of getting stack arguments
Date: Wed, 19 Apr 2006 07:55:00 -0000 [thread overview]
Message-ID: <200604191020.08044.ghost@cs.msu.su> (raw)
In-Reply-To: <20060418161654.GA15524@nevyn.them.org>
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
next prev parent reply other threads:[~2006-04-19 6:20 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 [this message]
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
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=200604191020.08044.ghost@cs.msu.su \
--to=ghost@cs.msu.su \
--cc=drow@false.org \
--cc=gdb@sources.redhat.com \
/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