This is the mail archive of the
mailing list for the GCC project.
Re: Some (small) c++ compilation profiling data (oprofile)
- From: dewar at gnat dot com (Robert Dewar)
- To: dewar at gnat dot com, neil at daikokuya dot demon dot co dot uk
- Cc: gcc at gcc dot gnu dot org, levon at movementarian dot org, mark at codesourcery dot com,zack at codesourcery dot com
- Date: Tue, 21 May 2002 20:58:54 -0400 (EDT)
- Subject: Re: Some (small) c++ compilation profiling data (oprofile)
> 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.
Sure you can certainly find anomolous cases, but still I am dubious whether
it can make that much difference if you keep everything else the same.
Recursive descent parsing is *so* fast that it is hard to believe that
it can ever be significant. The parser for Ada 83 that I wrote runs
at about 100,000,000 lines per minute on a moderate PC (the full parser
including lexical analysis is about ten times slower, since the lexer
takes 10 times the parse time, which is what I typically see over quite
a range of languages).
it is true that the language oddity in C of parenthesizing inline expressions
from macros does generate noise. It is quite easy to write a C parser so maybe
at least I will do that to compare with Ada, writing a C++ parser is more