This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Code Bloat g++


  In message <20000217115304.B13219@wolery.cumb.org>you write:
  > On Thu, Feb 17, 2000 at 08:39:58PM +0100, Martin v. Loewis wrote:
  > > > > > Anyway, as Alexandre points out: this is debugging information, so
  > > > > > what is the problem?
  > > > 
  > > > Argh!  I am astounded at how many C++ compiler developers make such com
  > ments.
  > > > I am familiar with a commercial project that is at a crisis point becau
  > se
  > > > of the massive, massive size of debug information generated by a
  > > > well-known proprietary C++ compiler (literally gigabytes of debug
  > > > information for a single medium-to-large application, more than triple 
  > the
  > > > size of the previous release).  Please let's not make g++ suck just as
  > > > badly.
  > > 
  > > That assumes that large debug information is redundant to a ridiculous
  > > degree. I don't know whether this is the case, but until I'm proven
  > > wrong, I'd always assume that every single bit in the debug
  > > information serves a purpose.
  > > 
  > > With that assumption, it is ok for me if debug information is large -
  > > because it could not be much smaller.
  > 
  > Stabs is in fact quite redundant, because everything is stored as
  > ASCII strings.  I've seen the size cut in half by using -gdwarf-2
  > instead.
Note that for stabs we have the ability to remove duplicate information
from the debugging sections.  We do not have that capability for dwarf2
right now.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]