Josh Stone <[email protected]> writes: > struct Dwarf_CU > { > @@ -283,7 +285,9 @@ struct Dwarf_CU > size_t type_offset; > uint64_t type_sig8; > > - /* Hash table for the abbreviations. */ > + /* Simple array for the abbreviations with low codes. */ > + Dwarf_Abbrev *abbrev_array[CU_ABBREV_ARRAY_SIZE];
This blows up Dwarf_CU from 100odd bytes to something like half the page, I'm not entirely fond of that. Especially since the hash table that follows is an on-demand-growing structure, having half a page reserved (possibly on stack) just in case seems wasteful. I'm looking into some debuginfo files. libc has an average of 28 abbreviations per CU (with 108 being the most), libstdc++ an average of 77 (with 108 the most), gcc 88 (142), libbost_python 206 (290), vmlinux 112 (185). So reserving space for 256 seems overly generous. I'd be fine with a growable heap-allocated array capped at 256. Hopefully that would still be helpful performance-wise. > --- a/libdw/libdw_findcu.c > +++ b/libdw/libdw_findcu.c > @@ -105,6 +106,7 @@ __libdw_intern_next_unit (dbg, debug_types) > newp->version = version; > newp->type_sig8 = type_sig8; > newp->type_offset = type_offset; > + memset(newp->abbrev_array, 0, sizeof(newp->abbrev_array)); Space after memset. That sizeof either shouldn't have parens, or there should be a space. Thanks, PM
