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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

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

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

It turns out that we can make it start very fast by assuming that if we
see .debug_gnu_index, then we are going to use both it and
.debug_aranges.  I changed the code to make this assumption, and to
lazily map all debug sections.  With this in the place the results are
ridiculously great, like:

    0.15user 0.02system 0:00.21elapsed

I also found out that testing this code with "gdb -batch" introduces a
bit of confusion into the results, because that will call
find_main_filename, which will require some symbol table information.
I've taken to disabling this code when looking at timings.

Also, I made another funny hack tonight.  I changed gdb to read
.debug_aranges and .debug_gnu_index in a background thread.  This was
pretty easy to do; it really just few a couple global __thread
variables.  (I didn't attempt reading full symbols in a separate thread,
because that seems a lot more involved.)

What this means is that the user will still see very fast startup times,
but also will typically have less waiting when he runs a command.  The
problem with this "fast" patch is that we are really just deferring some
work until it is needed.  But, when it is needed we still have to spend
the time to actually read the index.  Threading lets us hide a bit of
that work.

I would guess that threading will be met with revulsion :-).  But, it
seems very practical in this case.

I'll clean up this patch a bit and push it to a new branch in archer
this week.

Tom