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