RE: [boost] Re: Wave C++ Review Begins Today - February 7, 2005

From: Hartmut Kaiser (HartmutKaiser_at_[hidden])
Date: 2005-02-17 13:32:14

Michael Walter wrote:

> > Thanks!
> > Defintely it is usable in more sophisticated contexts, even 
> if it is 
> > slower than gcc.
> 
> Apologies if this was already discussed further above: How 
> much slower is wave in your experience than gcc, and do you 
> have ideas where that comes from?

The speed difference depends heavily on the complexity of the code to
preprocess it may range from factor 2 upto factor 10. Compared to other more
or less conformant preprocessors (such as EDG) Wave is comparable or
slightly slower in speed for simple macro expansions and way faster in
complex cases.

The reasons for this are:

A) Even if the reviewed version of Wave is 1.1.13 and the project is alive
for slightly more than 3 years now, this is (from the design point of view)
still the initial version. My main goal for this first version was
conformity and flexibility but not performance.

B) As I know today, Wave has much room for performance improvement such as
for instance using a token class which is more efficient wrt copying
(pointing to a symbol table and not carrying the symbol text itself). But
because of Wave's modularity it is very simple to use such, essentially this
comes down to changing a single template parameter.

C) Paul Mensonides currently tries to convince me to completely re-implement
the macro expansion engine, which along the lines should speed up things.

D) As performance analysis showed, Wave currently spends 
  . about 30% of the required time parsing (with Spirit) the input for
preprocessor directives and parsing/evaluating expressions in #if/#elif
directives. This is way too much and I hope the picture will change when the
new version of Spirit will be available. 
  . another 35% of the execution time Wave spends in the flex_string code.
This may be changed by avoiding exessive string copying (as I pointed out
above, by changing the token class implementation). Another option is to use
a more efficient string implementation such as the const_string developed by
Maxim.
  . about 10% of the time is spent for memory allocation/deallocation - this
is tightly connected with the string problem, so I hope to get rid of this
as stated above.
  . about 15% of the time is spent inside of list's and vectors's members,
which is tightly coupled to the macro expansion process. I hope to lessen
this during the rewriting of the macro expansion engine.

E) the overall preprocessing could be sped up by implementing more efficient
file lookup techniques, such as file name caching and/or automatic detection
of "#pragma once" candidate files (through analysis for guards).

Hope this answers your questions.
Regards Hartmut