Re: Initial psymtab replacement results

[Daniel Jacobowitz <drow@false.org>]

I've been thinking about this.  You've done some nice work already, so
even though I have expressed concern about it I really want it to end
up merged and useful.

On Tue, Dec 15, 2009 at 04:38:58PM -0700, Tom Tromey wrote:
> The 'byname' index really slows down populating the database.  It took
> more than a minute to write out the database for gdb.  However, without
> the index, name lookups are extremely slow (as in, I can count to 2
> seconds when running a select command in sqlite3).

Did you create the index, then populate the table?  Is it quicker to
populate the table, and then create the index?

> Daniel> Mappable data structures are tricky; one thing I'd definitely
> Daniel> insist on is host neutrality.  IMO that is not optional.
> 
> Yeah, that does make it trickier.

Frank made a good point about putting host characteristics in the
cache key.  By careful choice of the types stored, we should be able
to create a mapped data structure that is in practice dependent only
on endianness and maybe pointer size.  WDYT?

If it's a pointer-swizzled index (i.e. update pointer offsets when
writing and reading), then we'd have to read the whole index into
memory instead of mmapping it; but in exchange we'd get to use zlib
when streaming the index to disk, and the data is probably highly
compressible.  I don't know which of these turns out to be faster
in real-world scenarios (cold and hot cache).

I know you've done a lot of work to kill psymtabs.  Do we populate
psymtabs from the index, or are they pretty much optional now?  In
other words, can we reclaim and reuse the memory formerly spent on
psymtabs?

> I think we ought to change GCC to drop the .debug_pub* sections (and
> maybe .debug_aranges), at least on Linux.  AFAIK they aren't used by
> anything, and indeed are barely usable due to historic bugs -- so they
> are just wasting time and space.

I don't know whether third party debuggers use the existing
.debug_pubnames.  I wouldn't be surprised either way.

-- 
Daniel Jacobowitz
CodeSourcery