This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?


> 
> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]