This is the mail archive of the
mailing list for the Archer project.
Re: Initial psymtab replacement results
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Fri, 11 Dec 2009 16:09:49 -0700
- Subject: Re: Initial psymtab replacement results
- References: <email@example.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Tom" == Tom Tromey <firstname.lastname@example.org> writes:
Tom> * Test out using pubnames + pubtypes instead of the new section.
Tom> I remain skeptical about this but it seems important to be sure.
I thought of a way to approximate the performance of this without
actually implementing it.
According to my theory, the most important thing is to avoid reading
.debug_info (et al) during startup. And, we already know that using
.debug_pub* will require reading the CU DIE. So, I simply modified gdb
to always read the CU DIE.
GDB Cold Cache Warm Cache
baseline 1:24 0:56
branch 0:45 0:19
DIE 0:54 0:21
So... it is worth about a 15% speedup in the cold cache case. Still, it
is hard to know whether this is justified in terms of the overall
effort. OO.o is a pretty big program, and 10 seconds doesn't exactly
give the user that "wow" factor.
I'm leaning toward ditching the .debug_gnu_index idea and simply going
with the standard sections instead. Let me know what you think of this.
As far as I know the .debug_pub* approach is ok assuming (1) we take
Cary's suggestion of changing gcc to put everything in it, and (2) parse
the producer to see when the sections are usable.
Jan mentioned on irc yesterday that we could probably do better by
avoiding reading any debuginfo at all during startup. For the "attach"
case we could additionally use info from the inferior to determine which
objfile the PC is in -- so we would not have to read anything from most
objfiles. (Perhaps in conjunction with lazily reading minimal symbols.)
The possible issue with this is latency. This is what bit us with the
delayed-symfile branch: we could hide the initial work easily, but it
was (very) noticeable later, because gdb would pause for a long time in
response to some user command.
To look at this, I instrumented gdb to print the amount of time taken to
read the index for each objfile. There were 170 objfiles with debuginfo
in OO.o, with a median reading time of 7999 microseconds, a mean of
30277 microseconds, and a maximum of 641903 microseconds.
This indicates to me that the latency problem would not be severe for
the PC-lookup case.
However, I think it would be just as bad as delayed-symfile for the
name-lookup case, because name-lookup doesn't let us pick the needed
objfile a priori. Perhaps this is an area where the threaded branch can