This is the mail archive of the
mailing list for the GCC project.
Re: gcc compile-time performance
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: neil at daikokuya dot demon dot co dot uk, gcc at gcc dot gnu dot org, robertlipe at usa dot net
- Date: 18 May 2002 14:40:56 +0200
- Subject: Re: gcc compile-time performance
- Organization: CodeSourcery, LLC
- References: <20020518121939.659BCF2A59@nile.gnat.com>
firstname.lastname@example.org (Robert Dewar) writes:
| > 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.
| Well for sure there is no reason to spend any measurable amount of time
| in parsing (or lexical analysis for that matter), but I have certainly
| seen compilers that manage amazingly to spend significant amounts of
| time in these functions, typically from the use of inefficient tools.
| Is this really a time eater?
Some beleive so, and I don't have data to the contrary.
| Often I see in the g++ world the phrase
| "parsing" to encompass what in normal terminology is both parsing and
| static semantic analysis, and most certainly the static semantic analysis
| in C is non-trivial and potentially time consuming.
Parsing C/C++ require semantic actions, so some semantic analysis is
inherently part of parsing C/C++.