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: Matt Austern <austern at apple dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: Neil Booth <neil at daikokuya dot co dot uk>, Joel Sherrill <joel dot sherrill at OARcorp dot com>, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, Phil Edwards <phil at jaj dot com>, "Michael S. Zick" <mszick at goquest dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 10 Feb 2003 16:56:40 -0800
- Subject: Re: GCC 3.3 compile speed regression - AN ANSWER
On Monday, February 10, 2003, at 04:47 PM, Alan Modra wrote:
On Mon, Feb 10, 2003 at 11:31:15PM +0000, Neil Booth wrote:
Joel Sherrill wrote:-
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.
Oohhh. Is this a serious attempt at passing the buck? 8-)
(No, this post isn't serious and doesn't really merit a response).
Heh. In certain cases, ld indeed spends considerable time attempting
to
merge strings. See
http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg01403.html
Broad generalization, based on the numbers I've looked at: for the kinds
of C++ projects that Apple cares the most about, the vast majority of
time
is spent in cc1plus. as is in the noise. ld can take a lot of time
for a
large multi-file project, but, of course, the compiler will also take a
lot
of time if you're compiling a lot of files. The case where ld overhead
is
interesting: you've got a huge project, you've already built it, you
change
one or two source files, and you run 'make' again.
In other words: we aren't off the hook. The slow part of compiling is
the
compiler.
--Matt