This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 compile speed regression - AN ANSWER
- From: <tm_gccmail at mail dot kloo dot net>
- To: Per Abrahamsen <abraham at dina dot kvl dot dk>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 11 Feb 2003 11:16:19 -0800 (PST)
- Subject: Re: GCC 3.3 compile speed regression - AN ANSWER
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