Re: [RFC]: New dwarf2 reader

[Daniel Berlin <dan@www.cgsoftware.com>]

On Fri, 29 Jun 2001, Michael Snyder wrote:

> Daniel Berlin wrote:
> >
> > Still a work in progress, however, i'm only bugfixing now, as i'm
> > happy with memory usage, etc.
> >
> > Changes:
> > 1.
> > This has an improved implementation of removing duplicates. It's done
> > basically the same way gcc does it, which is to actually just go all out and md5
> > checksum the attributes of dies.  Conservatively, of course.
> > Currently, this means that duplicate things with different offsets for their
> > types, siblings, etc, don't get eliminated.
> > I'll improve this in a bit (We'll ignore the sibling attribute for
> > checksum purposes, and a few other minor twiddles.)
> >
> > You'd think that the fact that the relative placement inside the
> > section mattering would stop us from eliminating most duplicates.
> > You'd be very wrong.
> >
> > GCC, by deferring output a lot, tends to end up outputting things in
> > the same order.
> >
> > We are now down to 21 meg of memory to debug gdb, with all symbols
> > fully read in.
> > Down from 80.
> >
> > STABS takes 22 or 24, I forget which.
>
> Daniel, this is a very promising development.  Have you done any
> timing checks?  How long does it take to load all those symbols
> and remove duplicates, compared to the old code?

Yes, as some of you may know, i can be an optimization freak at times.

It takes 14 seconds, vs 7-8 for the old.  However, most of the time is
spent in the splay tree routines.  At least, a few weeks  ago, it was.
I'll reprofile.

Certainly, the md5 ends up not being much of a factor, because you can md5
at >30 meg a second on a pentium 133.
:)

I'm happy as long as the profiling data shows splay tree routines at the
top, and at 30-40% of the time. Because I can just move to a hash table
for that stuff, and get better performance.

So, all in all, i'm not too worried that it's slower right now.

 >