Re: [RFC] Proposal for a new DWARF name index section

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> Well, as long as I'm not the one who has to convert the C++ demangler
Daniel> into a specification, I guess it's not totally crazy.  I still think
Daniel> this makes more sense as an internal cache, though, because it's so
Daniel> tied to the implementation of both the compiler and debugger.  And
Daniel> the canonicalization isn't cheap, and doesn't match GCC's internal
Daniel> representation of the names; this would slow down GCC to speed up
Daniel> debugging.

I do think that slowing down the compiler to speed up the debugger would
be the wrong tradeoff.  I was hoping we could get this for free in the
compiler, or nearly so, but now I unfortunately see that I was confused
on that point :-(.  We could pick a representation close to what gcc
already emits -- but then that overly constrains gcc in the future.


Caching is interesting but it comes with other problems.  We have to
manage the cache somehow.  And, the cache would not be useful when an
object changes.  So, I'd prefer a direct approach, if one can be made to
work.


The index is still an improvement even if we have to do canonicalization
when reading.

Some initial numbers:

                           warm cache    cold cache
 without canonicalization:  ~0.5 sec       5 sec
gdb does canonicalization:  ~1.7 sec       6 sec
             gdb cvs head:  ~2.4 sec      10 sec

There's a fair amount of noise in the warm cache numbers, I'd say +/-
0.2 sec.

This is timing "gdb -batch" on a smallish (80 KLOC) C++ program.  I
still haven't tried my big tests, I'm still working on setting those up.
I also still haven't tried the pubnames/pubtypes index.

I guess canonicalization is not terrible -- I definitely notice it when
the cache is warm, but with a cold cache it doesn't matter.

Tom