Re: PATCH: per-inferior register cache for gdbserver

[Michael Snyder <msnyder@redhat.com>]

Daniel Jacobowitz wrote:
> 
> On Sat, Apr 20, 2002 at 02:48:49PM -0400, Andrew Cagney wrote:
> > >Moving right along.  This is the initial per-inferior register cache
> > >interface; in my development sources (which are almost ready for
> > >submittal) the interface is actually somewhat different, but that's
> > >entangled with the rest of threading right now.  I'll be extracting it in
> > >the next few days.
> > >
> > >So, this patch is a step on the road, but don't get too attached to the
> > >interface.  It'll be much nicer, I promise.  This version works as-is,
> > >which
> > >I can't say for the nicer one at the moment.
> >
> > Um, would there be more benefit in getting this sort of thing
> > implemented in the core of GDB?  I just don't see a per-lwp cache in the
> > remote target making much difference to GDB's thread debugging performance.
> 
> There would be more benefit in doing it in GDB, certainly.  But like a
> lot of optimizations I'm doing in the server right now, this is
> beneficial to the server itself.  Note that I completely replaced the
> global cache; I switch back and forth amongst LWPs during operations,
> sometimes.  It simplifies life in the server greatly if I can just say
> "give me this thread's current registers" and let the register cache
> handle the details.
> 
> In GDB, this would be a performance optimization; in the server it's
> there for simplicity more than anything else.  It also lets me delay
> register fetching for other threads until it's actually needed, which
> it may never be (in the next version of the cache, which has valid
> flags).  I can get numbers later on how many register fetches it
> actually saves; I suspect it's fairly small.

For what it's worth, I explored a lot of things like this
(including exactly this, I think), when I was re-writing
procfs.c.  In the end, they resulted in no measurable performance
improvement at all.   ;-|

But I had fun playing around with them, of course...

Michael