This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/13498] save-index makes gdb slow with dwarf4


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]