From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@apple.com>
Cc: Mickael Gicquaire <Mickael.Gicquaire@st.com>, "gdb@sources.redhat.com" <gdb@sources.redhat.com>
Subject: Re: gdb benchmarking and profiling
Date: Thu, 09 Aug 2001 12:13:00 -0000
Message-id: <3B72E0BA.50007@cygnus.com>
References: <1010808103350.ZM10068@bristol.st.com> <3B717B0D.CD7CF49E@apple.com>
X-SW-Source: 2001-08/msg00086.html

> In my view (which may be out of date), there are two key areas to
> look at when considering GDB performance.  The first is symbol
> reading.  Believe it or not, this is almost always a CPU-bound
> activity - BFD doesn't take very long to read even large chunks
> of debug info, and the rest of the time is spent turning the raw
> info into GDB symbolic info.  Thus partial symbol tables for
> instance, the theory being that you're usually not interested in
> a function's local variables until you've actually stopped in
> that function.  gprof profiling works well for studying this,
> just run in batch mode.


Ok.


> The second area is the efficiency of the debug protocol.  This
> is ultra-critical for remote debugging over serial lines, but
> still matters even for native ptrace debugging.  The game here
> is to count the bytes going back and forth, and the number of
> interchanges (or context switchesa) between GDB and the inferior.
> For instance, sometimes GDB needs to analyze a function's
> prologue in order to determine where the arguments are stored,
> so it knows how to do a backtrace.  It would be very inefficient
> to pull the function's instructions from the target, since (usually)
> the same instructions are readily available in the executable.
> Another example that was touched on recently was the size of
> memory reads - GDB tends to read whole words, even if it only
> needs a single byte.  (Of course, if the word is cached once
> read, then the next byte is readily available.)  There are all
> kinds of opportunities to make GDB interact with the target
> more efficiently, just start studying the packets; "set targetdebug"
> is helpful to get started.


I don't know that bandwidth is still the most common problem (except 
where an architecture has millions of registers :-).  Rather it is 
latency.  Latency shows up in the number of round trips needed to 
achieve anything useful.  A few extra bytes here or there are in the 
noise :-)

The other is GDB's complete inability to hang onto anything when doing 
stuff like switching threads.

	Andrew