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: Linus Torvalds <torvalds at transmeta dot com>
- To: Matt Austern <austern at apple dot com>
- Cc: jsm28 at cam dot ac dot uk, <gcc at gcc dot gnu dot org>
- Date: Tue, 11 Feb 2003 22:19:38 -0800 (PST)
- Subject: Re: GCC 3.3 compile speed regression - AN ANSWER
On Tue, 11 Feb 2003, Matt Austern wrote:
>
> All of my measurements suggest that improving the speed of optimization
> phases is irrelevant. What's slow is the front end: parsing and
> semantic analysis. -O0 compilations are slow, not just -O3.
I wouldn't disagree, although I suspect that the truth is slightly more
complicated than that.
For example, I assume that you've done most of the measurements on C++
code, especially the problem cases (ie large header files, lots of
inclusions etc). The KDE/Qt kind of loads or whatever the equivalents are
at Apple.
And yes, that is very front-end-heavy. In fact, 99% of the code parsed in
that kind of environment should probably never generate any actual
back-end activity AT ALL in that kind of environment, and should only ever
get as far as semantic parsing and storing into the parse tree.
And making the front-end lightweight is a HUGE win because of that. You
want to make semantic parsing as light-weight as possible, because a lot
of the stuff you parse is never going to be used. It's declarations in the
header files that _can_ be used but mostly only a small subset of it
actually is.
I'm guessing here, but I'd not be surprised if a few-hundred-line GUI C++
file would tend to easily explode to a hundred _thousand_ lines with
include files fully expanded. The front end is involved with all of them,
while the back-end is really only involved with the original few hundred
lines and some code expansion from inlining and macros.
Add to that that C++ is harder to parse semantically in the first place,
and I'm not surprised if you find the front-end being a major concern.
But that should be a smaller issue on traditional C programs that don't
tend to include everything through a header file that needs the world.
There the ratio of "real meat" to "scaffolding" is likely to be rather
different.
But it still boils down to the same thing: you don't want to go over the
data structures and convert them in between phases. You generate a ton of
data the first time through, you'd rather not touch it later (much less
convert it) unless you really need to.
Linus