[Dwarf-discuss] Re: dwarf2 question [abbreviations]

[Mathieu Lacage]

[removed CCs]

On Thu, 2005-03-03 at 12:53 -0500, Daniel Berlin wrote:
> > Normally the number of abbreviations for a single .o is quite small.
> > And involves only very small abbreviation numbers.
> > 
> > If a compilation system were to somehow merge abbreviations tables
> > a single table might grow large, but  that's off the point I think.
> 
> > 
> > You will need to fall back to allowing arbitrary order when
> > you find something out of order within a particular abbreviation table.
> > 

Yes, I did that. 

For the record, I have implemented a linear hash table with 16 entries
which caches the location of 16 abbreviations by abbrev number. The
cache logic is smart enough to return the location of the closest
abbreviation whose number is lower than the target abbreviation. This
works like a charm and gives me a 20x speedup for a 97 bytes cache which
is cleared at the start of every dwarf2 lookup. Bigger caches did not
really improve the speed.

> I'm also not sure parsing abbrev tables is all that memory intensive.

It is not but I am trying to make my parser not dynamically allocate any
memory and, generally, have a very very low memory footprint. One of my
long-term goal is to use this code in really bad situations when things
have started to be screwed really badly so I am being a bit paranoid and
try to avoid any call to outside libraries.

Currently, read_uleb128 represents 60% of the runtime as reported by
oprofile and the cache lookup code represents 8% while the code which
locates abbreviations has disapeared from the profile. I guess I could
spend some time optimizing my uleb reading code :)

thank you all for your answers,
Mathieu
--