GCC 3.3 compile speed regression - AN ANSWER

[tm_gccmail@mail.kloo.net]

On Tue, 11 Feb 2003, Per Abrahamsen wrote:

> Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> 
> > Has anyone looked at how much the binutils contribute to the end to
> > end performance question?  gas is involved in every compile and ld is
> > involved in every program link.  I just don't recall it every being
> > mentioned.
> 
> Speeding up ld would help my edit/compile/run cycle far more than
> speeding up gcc.  
> 
> Probably because gcc typically only have to compile one file after an
> edit, while ld has to link 219 files.
> 
> Of course, for the rare cases where I have to build from scratch, gcc
> is dominating.

When I was at Sega, the main complaint we had from gcc developers was
the slow link/debug time. The typical scenario would be:

1. Developer has a project with a 4 megabyte memory footprint

2. Executable for the aforementioned project would be about 80 megs
   due to large amounts of debug info

3. Linker requires 2-3 minutes to link due to large amount of debug info

4. Debugger requires 2-3 minutes to load file

So basically, the cmopiler emitting redundant debug info probably added
about 4-5 minutes to the compile/link/test turnaround cycle.

We wound up recommending that people use RAMdisks for linking, which would
reduce the link time by about half and shave a little over minute off the
compile/link/test cycle.

Toshi