gdb index performance

gdb index performance

[Tom Tromey]

Jan asked for a bit more data on the performance benefit of the gdb
index work.

I ran tests on 2 machines (PPC and x86 -- I still need to try x86-64).
First, I installed a program plus all its debuginfo; I chose abiword for
the PPC box because the I have access to didn't have enough free space
for all the OO.o debuginfo, for x86 I used OO.o writer.  Then I ran a
script to generate all the .index files in /usr/lib/debug.

Then I ran 3 "attach" tests, 5 times each.  For the first set of tests I
cleared the file caches before each one; for the second set I cleared
the caches but then put gdb itself into the cache, to try to isolate its
startup time; the third set I ran with a warm cache.

I also did the same tests, but including "thread apply all bt full".
This helps negate the effect of the aranges-reading code, by forcing
some psymtabs to be read.

I did this for a recent-ish gdb master, the system gdb (in each case a
Fedora gdb, so it has the aranges code but nothing else), and then the
branch that uses the indices.

The results are appended.  All times are in seconds, elapsed time only,
average of all 5 runs.

I think the results are ok, though not quite as super as I had wanted.
The warm cache "bt" results are particularly good (actually I thought
something went wrong so I did this again by hand -- it really is that
fast) for the index approach, but I don't know how representative those
are of any real-life scenario.

We could probably make the cold-cache case a bit better by moving the
index file mapping into the background.  Also these numbers suggest that
there are some other performance problems we could attack; profiling
shows that minimal symbols and also name canonicalization (of minsyms)
are expensive.

I can email my scripts to anybody who is interested.

Tom

PPC attach results:

+----------+----------+----------+----------+
|       gdb|      cold| cache gdb|      warm|
+----------+----------+----------+----------+
|    system|     15.57|     14.02|      2.99|
+----------+----------+----------+----------+
|    master|     21.00|     19.35|     10.50|
+----------+----------+----------+----------+
|    branch|     11.02|      9.89|      1.87|
+----------+----------+----------+----------+

x86 attach results:

+----------+----------+----------+----------+
|       gdb|      cold| cache gdb|      warm|
+----------+----------+----------+----------+
|    system|     47.76|     44.31|      2.93|
+----------+----------+----------+----------+
|    master|     73.07|     66.91|     13.10|
+----------+----------+----------+----------+
|    branch|     40.20|     36.29|      2.51|
+----------+----------+----------+----------+


PPC bt results:

+----------+----------+----------+----------+
|       gdb|      cold| cache gdb|      warm|
+----------+----------+----------+----------+
|    system|     22.64|     20.92|      6.98|
+----------+----------+----------+----------+
|    master|     22.12|     20.31|     11.08|
+----------+----------+----------+----------+
|    branch|     12.50|     11.56|      2.11|
+----------+----------+----------+----------+

x86 bt results:

+----------+----------+----------+----------+
|       gdb|      cold| cache gdb|      warm|
+----------+----------+----------+----------+
|    system|    110.02|    123.06|     17.53|
+----------+----------+----------+----------+
|    master|     78.75|     71.47|     14.85|
+----------+----------+----------+----------+
|    branch|     51.84|     47.07|      3.07|
+----------+----------+----------+----------+

Re: gdb index performance

[Jan Kratochvil]

On Wed, 23 Jun 2010 21:43:02 +0200, Tom Tromey wrote:
> I also did the same tests, but including "thread apply all bt full".

Wasn't there a problem with incomplete backtraces (due to prelink) such as
shown at the top of:
	http://sourceware.org/ml/gdb-patches/2010-06/msg00515.html
	

> The warm cache "bt" results are particularly good (actually I thought
> something went wrong so I did this again by hand -- it really is that
> fast)

Just to be sure - assuming the machine had enough RAM.  # of CPUs?


"cold" on SSD storage could hopefully be more like "warm".
(i do not have SSD here.)


Thanks,
Jan

Re: gdb index performance

[Tom Tromey]

Jan> Wasn't there a problem with incomplete backtraces (due to prelink) such as
Jan> shown at the top of:
Jan> 	http://sourceware.org/ml/gdb-patches/2010-06/msg00515.html
	
For the abiword (PPC) case I manually checked the backtraces and it all
seemed reasonable enough.

Ugh, I looked at the x86 case and it turns out I need a merge from
master to pick up some unhandled DWARF operators.  Sorry about that.

>> The warm cache "bt" results are particularly good (actually I thought
>> something went wrong so I did this again by hand -- it really is that
>> fast)

Jan> Just to be sure - assuming the machine had enough RAM.  # of CPUs?

The PPC box has 2 CPUs.  It seems to have a lot of memory (3G).

The x86 box is my laptop, 1 CPU.  It has 1G of RAM.

Tom

Re: gdb index performance

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> Ugh, I looked at the x86 case and it turns out I need a merge from
Tom> master to pick up some unhandled DWARF operators.  Sorry about that.

New x86 results.

attach:

+----------+----------+----------+----------+
|       gdb|      cold| cache gdb|      warm|
+----------+----------+----------+----------+
|    system|     44.91|     41.68|      2.90|
+----------+----------+----------+----------+
|    master|     71.06|     66.57|     13.08|
+----------+----------+----------+----------+
|    branch|     41.51|     38.07|      4.54|
+----------+----------+----------+----------+

thread apply all bt full:

+----------+----------+----------+----------+
|       gdb|      cold| cache gdb|      warm|
+----------+----------+----------+----------+
|    system|    116.16|    110.43|     16.46|
+----------+----------+----------+----------+
|    master|     74.65|     70.57|     14.75|
+----------+----------+----------+----------+
|    branch|     49.65|     46.55|      5.62|
+----------+----------+----------+----------+

Tom