This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb benchmarking and profiling
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: gdb benchmarking and profiling
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 09 Aug 2001 15:12:58 -0400
- Cc: Mickael Gicquaire <Mickael dot Gicquaire at st dot com>, "gdb at sources dot redhat dot com" <gdb at sources dot redhat dot com>
- References: <1010808103350.ZM10068@bristol.st.com> <3B717B0D.CD7CF49E@apple.com>
> 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