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: "l.lunak at suse dot cz" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 20 Feb 2012 13:48:42 +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 #5 from LuboÅ LuÅÃk <l.lunak at suse dot cz> 2012-02-20 13:48:42 UTC ---
I'd like to point out again the second paragraph in comment #2. It's been a
while since I did this analysis, so I don't remember all the details anymore
and getting into it again would take some time, therefore this is a bit of
guesswork and trying to recall, but as far as I remember:
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.
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.
Again, this is just trying to recall things from 2 months ago with my limited
gdb knowledge, so you should verify this yourself, but I suggest first checking
gdb's performance in general when dealing with large dwarf-4-built .so files.
Maybe it'll be necessary to change all accesses to the CU-list (or whatever
it's called exactly) to be more efficient (compact it into less items,
hashtable for access, whatever).
Also, for the save-index case, since gdb creates the index on its own anyway,
it could possibly make sense to prepare it better for the completion case. As I
understand it, gdb always first collects all items for completion and only
afterwards it selects ones eligible for completion, so maybe the index could
also contain a sorted list of (references to) all completion items in the
matching .so, which presumably would take only relatively little space and
would make completion almost instant.
--
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.