Code Bloat g++

[Gerald Pfeifer]

On Thu, 17 Feb 2000, Joe Buck wrote:
> Of course squangling is a big win and I'm looking forward to the day
> that we can turn that on by default.

Not just you! ;-)

>> Real life debuggers also have large disk space and incremental linkers
>> :-)
> Those help, but can be insufficient when compiler developers who don't
> think about the issue for 2 gigabytes of virtual memory to do a link, and
> dozens of gigabytes to store all the .o files.  The first thing that dies
> is the network.  (no, g++ is not that bad.  Sun C++ 5.0 *is* that bad.  It
> seems that we need user pressure, from folks like me and Gerald, to keep
> g++ from getting that bad).

To be fair, Mark and Jason repeatedly have fixed problems in that area
( http://gcc.gnu.org/ml/gcc-bugs/1997-12/msg00361.html for example), but
current CVS sources do quite bad things to my machines again:
  
  http://gcc.gnu.org/ml/gcc/2000-02/msg00279.html

Here is some further data for a project which is *tiny*, compared to those
Joe mentioned:

                     2.95.2       2.95.2    2000-02-18 2000-02-18
                         -O        -O -g            -O      -O -g

  generate.ii        664810       664810        659323     659323           
  generate.s        1831798     25742797       1606146   22416940
  g++ -S             1:09.5       1:17.0        1:58.8     1:59.0
  as                    5.5      15:34.7           4.4    14:46.0
  gas                   2.9         36.1           2.2       43.3

Evidently, Sun as is quite inefficient, but note that huge size of the
.s file for such a small program. Also note that current CVS is much
slower than GCC 2.95.2!

This scales extremely bad for serious projects.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/