This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]