Re: gcc compile-time performance

[Gabriel Dos Reis <gdr at codesourcery dot com>]

dewar@gnat.com (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++.

-- Gaby