Re: Target changed, caching reg values in ``struct frame''

[Jim Ingham <jingham at apple dot com>]

On 3/16/02 12:21 PM, "Andrew Cagney" <ac131313@cygnus.com> wrote:

> Hello,
> 
> (I think this is more of an issue to GUI developers so I've directly
> pinged a few :-)
> 
> GDB has tried to improve its performance by having a number of
> target-changed (from target stopping) events.  For instance
> registers-changed (write to register) and possibly memory-changed (write
> to variable).
> 
> I've suggested previously that these refined events were not worth the
> effort.  If the programmer modifies something in the target (a rare
> event in its self, I don't remember the last time I modified the target)
> then it is definitly easier and simplier (and hopefully almost as fast)
> to just throw away GDB's local copy of the target's state and start again.
> 
> My question for the GUI people is, does any one have evidence supporting
> this?  Should GDB only concentrate on trying to tune target-changed
> (single step) performance and completly ignore the other cases
> (eliminating register-changed and anything else).
> 
> I know the Insight developers have so far concentrated on stepi.

When we were doing performance analysis on Project Builder, one of the big
time sinks we noticed for stepping was the call to -stack-list-frames.  We
weren't constructing arguments, this was just the accounting for saved
registers, prologue parsing, etc...  For very deep stacks (which most Object
Oriented programs seem to always have) this was particularly bad.

The problem, as I am sure you know, is that in a GUI you are always showing
the stack, so you need to see if it has changed at every step.  Any reliable
algorithm for doing this involves counting the stack depth, and getting some
kind of fingerprint of the stack.  But there is no way to do this in gdb
without building up the whole frame cache.  Since most users never select
stack frames above the top two or three when they are just stepping around,
most of this is wasted work.

I added a "ppc-fast-count-stack-depth" command to gdb (only for the PPC)
which either counts the stack, or alternately lists duples of the pc & frame
ptr for the stack.  This command is pretty much of a hack in that it doesn't
use any of the frame machinery, but just redoes the logic for PPC off to one
side.  But this gave us a noticeable boost in stepping speed - so as an
experiment I think it indicates that providing a fast way to do this is very
valuable.  

Having the frame pointer sent along is also nice because it is a very quick
fingerprint of the stack.  Remember for a GUI most of the time you really
want to know just how much of the stack has changed - and for stepping the
answer is usually "not much"...

Another example (non-gui) where this is really expensive is in function
calls deep in the stack.  When somebody in ObjC goes to make a method call,
we actually have to make several function calls into the inferior to bring
this about (look up the selector, lookup the implementation function for the
selector/object combo and finally call the implementation function).  If you
are doing this deep in the stack, you have to rebuild the frame cache up to
the frame in whose context you are calling this after each call.  This ends
up being a substantial portion of the time for these method calls...

Jim

> 
> --
> 
> (What is the secret plan?)
> 
> GDB has two types of registers:
> 
> - raw registers as found in the register cache
> 
> - frame registers as found via struct frame
> 
> Frame registers are constructed from raw-registers, memory, or the next
> inner most frame.
> 
> Would there be any performance gain in having ``struct frame'' cache the
> raw byte value of a frame register?  At present the frame contains the
> address of the saved register (for traditional frame code) (I'm not sure
> what it does for CFI frames).
> 
> I'm thinking that a key part of recovering from a stepi is the
> reconstruction of the ``struct frame'' chain.
> 
> Again, anyone got evidence supporting this?
> 
> --
> 
> enjoy
> Andrew
> 
> 

-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              jingham@apple.com
Developer Tools - gdb