This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some (small) c++ compilation profiling data (oprofile)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]