Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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