Re: [RFA] symtab/11942: rewrite dwarf2read.c type_hash usage

[Daniel Jacobowitz <dan at codesourcery dot com>]

On Mon, Aug 23, 2010 at 05:03:27PM -0700, Doug Evans wrote:
> The basic idea here is that instead of having one type_hash per CU,
> we have one type_hash for dies from .debug_info and have another type_hash
> for dies from .debug_types.  Types are hashed based on the associated
> die's offset and are not freed when a CUs dwarf2_cu structure is freed,
> thus I can't see a need for one type_hash per CU.

FWIW, I believe I chose this way for performance.  If we have the DIE,
we have the CU, and this keeps the hash tables smaller and makes it
easier to estimate their size.  Sure, lookups are O(1), but there's
also both cache behavior and the cost of resizing during read-in to
consider.  I did a whole lot of benchmarking, and the
"cu->header.length / 24" worked out well.

Things have changed since then, though, not least Tom's index support.

> Plus, when looking up a type for a given die, gdb first reads in the
> die at the given offset and then looks up the type for the die at that
> offset.  Since we hash types based on die offsets, I can't see a reason
> why we don't just lookup the type for the die at the given offset first,
> and only if that fails read in the die (this is useful, e.g., when
> dies have been flushed because the CU has reached max-cache-age).

This part makes total sense.  Duh!


-- 
Daniel Jacobowitz
CodeSourcery