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 #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.


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