This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.2 code bloat from debug info
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: glenn at aoi-industries dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 29 Nov 2003 01:41:17 -0500 (EST)
- Subject: Re: 3.2 code bloat from debug info
First, the subject line is off target. This is not code bloat; it is
debug info bloat. The debug info is not loaded into memory when you
run your program, so you don't have to worry about memory size, only
disk footprint.
You can see the true in-memory size (at the start of execution)
with the 'size' command. That's the size to compare if you are worried
about 'code bloat'.
Okay, now for the size of 'debug info bloat'.
gdb has a test suite of C++ programs. Unfortunately, these are all
small programs. I don't have any large C++ programs handy. If someone
wants to put up numbers for mozilla or open office, that would be cool.
This is on native i686-pc-linux-gnu, red hat 8.0, with binutils 2.14,
debug level 2 (-gdwarf-2 -2 and -gstabs+ -g2). This is total file size,
so it includes everything.
2.95.3 2.95.3 3.3.2 3.3.2
dwarf-2 stabs+ dwarf-2 stabs+
ambiguous.o 8940 9288 16128 18672
annota2.o 12428 15248 15040 22324
annota3.o 12428 15248 15040 22324
anon-union.o 3536 4104 3220 4592
casts.o 3900 4540 3504 4072
class2.o 7052 7488 6916 7528
cplusfuncs.o 24200 28648 24636 21140
cttiadd.o 3848 4500 3724 4024
cttiadd1.o 2464 3084 2388 2876
cttiadd2.o 3716 4352 3260 3664
cttiadd3.o 5200 5880 4524 4900
derivation.o 10624 11756 10312 11744
gdb1355.o 2784 3184 2940 3036
hang1.o 2612 3148 2516 3400
hang2.o 2240 3036 2116 3616
hang3.o 2188 2972 2084 3364
local.o 5100 6452 3788 5064
m-data.o 6560 7216 9640 10052
m-static.o 7404 8064 11896 12000
m-static1.o 1740 2784 1908 2792
member-ptr.o 15604 18504 18276 25660
method.o 4640 5356 4472 5236
misc.o 30688 29620 34688 40864
namespace.o 6872 7328 6552 6212
namespace1.o 1840 2696 1816 2420
overload.o 14504 16892 14844 15484
ovldbreak.o 14384 16544 14788 15772
pr-1023.o 4340 4976 3708 3988
pr-1210.o 4392 4796 5488 5952
pr-574.o 5856 6184 5308 5548
printmethod.o 4592 4960 4116 4288
psmang1.o 10464 9308 11992 9332
psmang2.o 19388 20684 23200 27828
ref-types.o 4196 4788 3788 4384
rtti1.o 10148 10620 10308 10628
rtti2.o 8968 9612 9996 10332
templates.o 64072 63456 63836 56148
try_catch.o 106192 91872 86136 121460
userdef.o 48180 33492 154452 195328
virtfunc.o 24284 25076 27364 27860
You can see that most of the sizes have gone down. Only two files have
increased more than 50% : ambiguous.o and userdef.o.
userdef.o increased because it includes standard header files and the
debug information for the standard header files is bigger than it used
to be. Real programs usually include standard header files, so this is
a real issue.
I don't know why ambiguous.o increased so much.
BTW, the gdb folks recommend dwarf-2 over stabs+. Note that if you
compile with just plain "gcc -g", gcc on native i686-pc-linux-gnu will
default to stabs+ with gcc 2.95.3 and dwarf-2 with gcc 3.2.2.
These are just the .o sizes. They don't include the size of the
standard C++ library, which increased substantially from gcc 2.95.3 to
gcc 3.3.2. The library size is a once-per-executable cost, and it is
additive, not multiplicative. That is, if you see a small executable
program go from 1 megabyte to 4 megabytes, it means that a large
executable program will go from 100 megabytes to 103 megabytes, not 400
megabytes.
I think that measuring the .o file sizes is a good metric. If you can
provide some of these sizes, it would help enlighten us. Please include
the version of gcc, the host and target triples, the debug format,
and the debug level (if not default, which is debug level 2).
Michael C
GDB QA Guy