From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Michael Snyder Cc: Subject: Re: [RFC]: New dwarf2 reader Date: Fri, 29 Jun 2001 19:34:00 -0000 Message-id: References: <3B3CED9B.8CAC8FB1@cygnus.com> X-SW-Source: 2001-06/msg00547.html 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. >