This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/13498] save-index makes gdb slow with dwarf4
- From: "tromey at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 20 Feb 2012 19:51:01 +0000
- Subject: [Bug gdb/13498] save-index makes gdb slow with dwarf4
- Auto-submitted: auto-generated
- References: <bug-13498-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13498
--- Comment #6 from Tom Tromey <tromey at redhat dot com> 2012-02-20 19:51:01 UTC ---
(In reply to comment #5)
> I think I concluded that this is not a localized problem in
> dw2_map_symbol_filenames(), but a design problem with the gdb internal
> structures. I had a patch for dw2_map_symbol_filenames() that would have worked
> sufficiently for me for that one specific problem, but I went back to dwarf-2
> anyway, and IIRC I decided that larger changes were needed that I wasn't
> feeling up to.
What I did today is look at all the places where we iterate over all
CUs and TUs when using the index. Then I went backward from here to
find the callers and thus construct test cases that may exhibit bad
behavior.
Aside from map_symbol_filenames, which I've already fixed locally,
there were only 2 such methods that could plausibly cause problems:
map_symtabs_matching_filenames and expand_symtabs_matching.
The former had a very bad performance bug in CVS HEAD:
http://sourceware.org/ml/gdb-patches/2012-02/msg00409.html
However, this is pretty new and I don't think it would have shown up
in your tests :-(
The test case for this one, with libooxlo.so is just:
break numberformatsbuffer.cxx:100
In my testing, the latter is slower when type units are present, but
not drastically so. The index speeds things up in both cases:
Normal Index
+-------+-------+
DW3 |0:07.61|0:01.76|
+-------+-------+
DW4 |0:08.80|0:03.45|
+-------+-------+
I plan to look into this one a bit more.
The test case here is:
info function CRYPTO
> Specifically, I think I found the bottleneck to be
> dwarf2_per_objfile->n_type_units being a large number in general that slows
> down more operations than just the one specific example given. As I understand
> it dwarf-2 had this number quite low, so it wasn't a problem, but dwarf-4 by
> design causes the number to be much higher.
Yes, in DWARF < 4, there are no type units.
BTW you might wish to use -gdwarf-4 -fno-debug-types-section.
This gets you some DWARF 4 benefits without type units; it should be
a pure improvement over DWARF[23].
I'm definitely interested if you know of other specific things that are
too slow.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.