From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Berlin <dan@dberlin.org>
Cc: Jim Blandy <jimb@cygnus.com>, Petr Sorfa <petrs@caldera.com>,
Daniel Jacobowitz <drow@mvista.com>,
gdb@sources.redhat.com
Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
Date: Mon, 04 Feb 2002 17:13:00 -0000 [thread overview]
Message-ID: <3C5F31A8.9060502@cygnus.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0202041203250.26583-100000@dberlin.org>
>
>
> Here's a question to think about as we move towards that:
> Where should the cache be?
>
> If you are using oft-computed expressions, we should be able to cache them
> if the information they depend on hasn't changed.
>
> Should each thing that implements the functions above handle caching
> internally, or should we put it one level above, and add functions to make
> generic queries like "is this location going to change if the x
> register changes".
>
> Assuming the queries are cheap, you could simply walk the changed
> values in the frame, ask if if any matter, and if not, you don't need
> to redo the calculation/value.
Relatively speaking I'd expect it to be cheap.
The most common case of something changing is when the target is
resumed. For this case, GDB has to invalidate everything and start
again from scratch. Hence, this is the case GDB needs to have working
fast. Initially, at least, register and memory writes can just be
treated like target resumes - target-changd.
Supporting this is varobj (well what I understand of it) Varobj tracks
variables identifying those that changed. It then provides a refresh
list to the UI (Insight or MI). While the computation necessary to
identify changed variables is singificant, it is nothing when compared
to the overhead of refreshing a variable's value on the screen. By
avoiding unnecessary refreshes, performance is significantly improved.
The other thing is that GDB has plenty of easier fixes when it comes to
caching: not flushing the cache when switching threads; pre-fetching
memory; ....
Anyway, as they say, get it working, then get it working fast; A slow
program shipped today is still quicker than a fast program shipped
tomorrow; ... :-^
--
Jim,
to throw a question in here. Where does this overall change leave
$frame? I'm suspecting that the existing frame code ends up being
pushed sideways and down covered by a new layer that lets you get at the
above.
enjoy,
Andrew
next prev parent reply other threads:[~2002-02-05 1:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-17 14:08 Petr Sorfa
2002-01-17 14:56 ` Daniel Jacobowitz
2002-01-17 15:07 ` Daniel Berlin
2002-01-17 15:10 ` Daniel Jacobowitz
2002-01-17 15:46 ` Petr Sorfa
2002-01-17 16:12 ` Daniel Berlin
2002-01-18 7:08 ` Petr Sorfa
2002-01-18 8:09 ` Petr Sorfa
2002-01-18 12:09 ` Daniel Berlin
2002-01-18 11:46 ` Petr Sorfa
2002-01-18 12:10 ` Daniel Berlin
2002-01-23 15:41 ` Jim Blandy
2002-01-23 16:18 ` Daniel Berlin
2002-01-23 16:36 ` Andrew Cagney
2002-01-23 17:10 ` Daniel Berlin
2002-01-23 16:38 ` Daniel Jacobowitz
2002-01-23 17:19 ` Daniel Berlin
2002-02-01 13:44 ` Jim Blandy
2002-02-04 9:13 ` Daniel Berlin
2002-02-04 17:13 ` Andrew Cagney [this message]
2002-02-15 12:47 ` Jim Blandy
2002-02-04 16:29 ` Andrew Cagney
2002-01-17 15:20 ` Andrew Cagney
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=3C5F31A8.9060502@cygnus.com \
--to=ac131313@cygnus.com \
--cc=dan@dberlin.org \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=jimb@cygnus.com \
--cc=petrs@caldera.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