This is the mail archive of the
mailing list for the GCC project.
Re: gcc compile-time performance
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: gcc at gcc dot gnu dot org, robertlipe at usa dot net
- Date: Sat, 18 May 2002 09:18:55 +0100
- Subject: Re: gcc compile-time performance
- References: <20020518020614.A5AC4F28EB@nile.gnat.com>
Robert Dewar wrote:-
> > Many of the "proprietary compilers" will shame GCC under the table for
> > compilation times. If you're knocking down a gig or more of source,
> > that absolutely does matter.
> Well in the case of Ada, GNAT compares reasonably favorably with other
> proprietary Ada compilers in compilation speed, and very favorably in
> terms of generated code, though there are exceptions to the latter.
> The front end of GNAT is very fast, so usually by far the larger part
> of the time is spent in the backend. How does this compare with the C++ case?
I think a big killer for GCC is the combination of overly-complex bison
parsers (necessary to keep state for various wacky things we want to do;
it's much easier to keep state for these things with a recursive descent
parser) and the genericity of "tree". I strongly believe this is a
performance issue in the C family of front ends; for example in the
C front end there are many contortions in place for no other reason
than we use bison.
[Not to mention that if "tree" died to become a bunch of separate tree
types something with the improved type safety that would imply, many of
the tree checking macros could die too, reducing bootstrap times.]