This is the mail archive of the
mailing list for the GCC project.
Re: gcc compile-time performance
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Robert Dewar <dewar at gnat dot com>, "jss at ast dot cam dot ac dot uk" <jss at ast dot cam dot ac dot uk>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sat, 18 May 2002 10:35:22 -0700
- Subject: Re: gcc compile-time performance
- References: <20020518132924.E6F40F2A59@nile.gnat.com>
--On Saturday, May 18, 2002 09:29:24 AM -0400 Robert Dewar <firstname.lastname@example.org>
>> I'd just be nice for gcc to be faster if that wasn't too hard to do!
>> Maybe precompiled headers would make a significant difference. Perhaps
>> gcc developers would like to get gcc's internals in a better state before
>> going down this line.
> It seems to me that if precompiled headers would make a huge difference,
> then they are patching a synmptom which is that the C++ front end is too
This is a common misconception. The problem is that sometimes (often)
the headers are the *vast* majority of the code in a single translation
unit. (Often, more than 95%). In order to be conformant, you must
not only lex and parse all of that code -- you must perform significant
Precompiled headers allow you to memoize all that work, and do just the
5% you really need to do.
The key underlying language design issue is that C++ headers are *not*
just interface declarations. If all we had to do was process some
"import" statements, as in Java, say, things would be simpler.
I'm not making judgements about the language; there are advantages
back and forth. The point is simply that the way the language is
organized puts certain burdens on the compiler.
> Mark, you were working on a new g++ parser, what's the story on that
Our customer asked us to work on something else instead. We're looking
for funding to finish the work. I may have good news on this front in
the near future, but I don't know yet.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com