From: Jim Ingham <jingham@apple.com>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: GDB List <gdb@sources.redhat.com>
Subject: Re: MI: type prefixes for values
Date: Mon, 20 Feb 2006 19:49:00 -0000 [thread overview]
Message-ID: <01627BAA-38C7-4391-A344-54B23B5F1863@apple.com> (raw)
In-Reply-To: <200602201026.15624.ghost@cs.msu.su>
Making variable objects is always slower than just printing the
values if you are only doing it one time. The variable objects don't
do any magic to get their values - they go through the same code as
"print" does ultimately, but they do a little more work getting
there. The overhead is not all that great, however. Just malloc'ing
some data structures and inserting them into a list somewhere.
The advantage of variable objects is that they cache the parsed
expression. So the second & third etc. evaluation is much faster.
This is a pretty common usage pattern, especially with local
variables, since you usually step a number of times in any given
frame, and the locals all have to be updated with each step. The
variable objects have some other convenient features, like the -var-
update command which refreshes the values will report only the
variable objects whose values have changed, so the front end has to
fetch less data.
It's been such a long time (~5 years) since we switched over to
variable objects in ProjectBuilder (now Xcode) that I don't have any
concrete numbers any more, sorry.
BTW, one of the things we added on our side was an option to -stack-
list-locals to make variable objects for all the locals it returns.
This is very convenient.
We also added the option to return all the locals in all the blocks
in a function. This allows you to present all the variables, and
then mark the ones which are not currently in scope appropriately. I
find this less confusing than having the contents of the variables
window come and go as you step through the function. Most of our
users seem to agree.
Jim
On Feb 19, 2006, at 11:26 PM, Vladimir Prus wrote:
> On Friday 17 February 2006 23:40, Jim Ingham wrote:
>> And... since the varobj's only parse the expression once when the
>> varobj is created, getting the current values of varobj's is much
>> faster than doing -data-evaluate-expression. Not a big deal if you
>> are just printing one value. But if you are trying to update all the
>> local variables on every step, this can be significant. People tend
>> to be pretty sensitive to the speed of the "step" operation...
>
> Hi Jim,
>
> can you provide some concrete numbers? Specifically, is using
> varobj to get
> values of all local variables faster then a single -stack-list-
> locals, and if
> so, by how much?
>
> Thanks,
> Volodya
next prev parent reply other threads:[~2006-02-20 18:57 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 9:09 Vladimir Prus
2006-02-17 10:22 ` Eli Zaretskii
2006-02-17 10:29 ` Vladimir Prus
2006-02-17 11:26 ` Eli Zaretskii
[not found] ` <200602171450.16858.ghost@cs.msu.su>
2006-02-17 13:49 ` Eli Zaretskii
2006-02-17 13:54 ` Daniel Jacobowitz
2006-02-17 14:08 ` Eli Zaretskii
2006-02-17 13:58 ` Vladimir Prus
2006-02-17 14:11 ` Eli Zaretskii
2006-02-17 14:26 ` Vladimir Prus
2006-02-17 14:36 ` Bob Rossi
2006-02-17 14:43 ` Vladimir Prus
2006-02-17 14:51 ` Bob Rossi
2006-02-17 15:02 ` Vladimir Prus
2006-02-17 19:25 ` Eli Zaretskii
2006-02-17 19:33 ` Daniel Jacobowitz
2006-02-17 19:36 ` Eli Zaretskii
2006-02-17 19:38 ` Daniel Jacobowitz
2006-02-17 19:56 ` Eli Zaretskii
2006-02-17 20:05 ` Bob Rossi
2006-02-17 20:07 ` Eli Zaretskii
2006-02-17 20:17 ` Daniel Jacobowitz
2006-02-17 20:28 ` Eli Zaretskii
2006-02-17 20:33 ` Daniel Jacobowitz
2006-02-17 21:14 ` Jim Ingham
2006-02-18 11:34 ` Eli Zaretskii
2006-02-20 13:47 ` Vladimir Prus
2006-02-20 8:11 ` Vladimir Prus
2006-02-20 19:49 ` Jim Ingham [this message]
2006-02-20 20:56 ` Daniel Jacobowitz
2006-02-20 20:57 ` Jim Ingham
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 21:33 ` Jim Ingham
2006-04-06 13:33 ` Vladimir Prus
2006-04-06 13:45 ` Daniel Jacobowitz
2006-04-06 14:05 ` Vladimir Prus
2006-04-06 14:31 ` Daniel Jacobowitz
2006-04-06 15:05 ` Vladimir Prus
2006-04-06 15:32 ` Daniel Jacobowitz
2006-04-06 18:53 ` Jim Ingham
2006-04-06 16:49 ` Jim Ingham
2006-04-06 16:49 ` Daniel Jacobowitz
2006-04-06 16:52 ` Jim Ingham
2006-04-06 18:58 ` Jim Ingham
2006-04-07 8:13 ` Vladimir Prus
2006-04-07 20:08 ` Jim Ingham
2006-04-12 15:38 ` Vladimir Prus
2006-04-12 19:41 ` Jim Ingham
2006-04-13 16:15 ` Vladimir Prus
2006-02-17 21:19 ` Daniel Jacobowitz
2006-02-17 20:20 ` Bob Rossi
2006-02-17 20:47 ` Daniel Jacobowitz
2006-02-17 19:44 ` Bob Rossi
2006-02-17 19:59 ` Eli Zaretskii
2006-02-20 7:28 ` Vladimir Prus
2006-02-20 23:37 ` Eli Zaretskii
2006-02-21 4:13 ` Daniel Jacobowitz
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 20:41 ` Daniel Jacobowitz
2006-02-20 13:48 ` Vladimir Prus
2006-02-17 11:27 ` Nick Roberts
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=01627BAA-38C7-4391-A344-54B23B5F1863@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