gdb: fix slowdown during skeletonless type units processing
My commit
6474c699a525 ("gdb/dwarf: sort dwarf2_per_bfd::all_units by
(section, offset)") introduced a pretty bad performance regression in
the "skeletonless type units" step. I have a pretty big executable
(Blender) compiled with -gsplit-dwarf (to generate .dwo files) and
-fdebug-types-section (to generate type units). Before the offending
commit:
Time for "DWARF skeletonless type units": wall 29.126, user 28.507, sys 0.497, user+sys 29.004, 99.6 % CPU
... and after:
Time for "DWARF skeletonless type units": wall 120.768, user 119.543, sys 0.651, user+sys 120.194, 99.5 % CPU
The reason for the slowdown is that add_type_unit now inserts type units
at the right place in the all_units vector to keep it sorted. These
repeated insertions in the middle of the vector require shifting a lot
of elements and end up taking a lot of time.
This patch fixes it by doing just one sort at the end of
process_skeletonless_type_units. The responsibility of keeping the
all_units sorted is delegated to the callers of add_type_unit. The
other two callers call finalize_all_units right after calling
add_type_unit.
One drawback that is probably not a real one: in
process_skeletonless_type_unit, we call process_type_unit. If something
in there needs to look up another type unit by (section, offset), it
wouldn't find it. I don't think that's a real issue though, as type
units are typically self contained. If a type unit needs to refer to a
type defined in another type unit, it would do so by signature, with
DW_FORM_ref_sig8. And during the indexing phase, I don't think we even
look at the DW_AT_type of things anyway.
With this patch applied, I am back to:
Time for "DWARF skeletonless type units": wall 29.277, user 28.632, sys 0.521, user+sys 29.153, 99.6 % CPU
I would like to cherry pick this patch to GDB 17, to avoid shipping GDB
17 with the performance regression.
Change-Id: I2a5b89ebca9e1a4e6248032e144520c9a579f47a
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33526
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>