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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> FWIW, I've used the following approach on a previous product X:
Paul> - As new binary is detected, a copy of X is invoked to parse all
Paul>   the needed debug info into internal form and written to a cache file.
Paul> - Once the copy exits, the cache file is directly mmap()ed by X.
Paul> - Cache files older than 1 week, and cache files prepared from
Paul>   binaries which no longer exist in their original location are
Paul>   pruned to keep cache size down.

Thanks.

FWIW, gdb used to have a caching scheme like that.  It has been a long
time, so I don't remember the details... I know that Jan had a
reimplementation of it last year, but found that it wasn't a real
performance win.  I don't recall why.

If we can get acceptable performance without a cache, then I think that
would be preferable.  One trouble with caching is that it is still slow
the first time.

So far, it is clear that we can improve performance.  It is less clear
whether we can improve it enough, but I'm working on finding out.

Paul> One of our typical usage scenarios is a tiny executable linked with
Paul> 1000+ C++ shared libraries. Simply re-running the test a second time
Paul> in a row in GDB takes 1+ minutes, as GDB discards and re-reads the
Paul> debug info for each solib (it used to take 6+ minutes before my dwarf
Paul> mmap changes).

It seems to me that we could be a bit smarter about objfile lifetimes.
I think this will probably be important for good performance in the
multi-inferior case.

Consider the classic "make check" example.  If we aggressively discard
objfiles as we do now, in this case we will be reading and throwing away
the debuginfo for gcc/cc1/etc for every object built by make... ugh.

Tom