This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Some (small) c++ compilation profiling data (oprofile)
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: levon at movementarian dot org, mark at codesourcery dot com, zack at codesourcery dot com,gcc at gcc dot gnu dot org
- Date: Tue, 21 May 2002 18:36:41 +0100
- Subject: Re: Some (small) c++ compilation profiling data (oprofile)
- References: <20020521090714.12CDCF28CE@nile.gnat.com>
Robert Dewar wrote:-
> I don't think that's such a bad idea, procedure calls are pretty cheap,
> and I doubt this is a source of any significant inefficiency. After all
> big complex expressions with multiple precedence levels are not common
> anyway statistically in most code. GNAT certainly does the same thing
> and does not mess with operator precedence. It's really a cleaner
> structure. Basic parsing (in the text book sense, no semantic analysis)
> using recursive descent should be an order of magnitude faster than
> lexical analysis anyway in practice.
Go to boost.org and have a look at the timings of various CPP tests
across compilers. One of them is a test of correctness of CPP
arithmetic; GCC 3.0.4 beats all of the UNIX competition (often
3 or 4 times faster). It is also sometimes 2 to 4 times faster than
2.95.2. Now, cpplib is quite a different implementation to 2.95.x
for macro expansion, so that could be a reason. But cpplib uses
an operator precedence parser, whereas cccp used a bison parser.
[Incidentally, on some of those tests, EDG blows up in its macro
expander, and takes about 4000 times longer for some reason 8-)]
For recursive descent, an example file Kaveh sent me about a
memory allocation bug a couple of weeks ago had a macro that
expanded to an expression with over twenty leading parentheses.
For recursive descent, I think each parenthesis would be handled
at the bottom of about 15 function calls with the C expression
grammar; cpplib's parser breezes through that far more quickly.
Neil.