I just changed the file to use spirit for parsing where I had used lexical_cast got very different timings for xpressive now, so now, with xpressive using a bit of spirit I get: Loop count: 10000000 Parsing: 42.5 xpressive: 15.4841 spirit-quick(static): 3.01117 spirit-quick_new(threadsafe): 3.10548 spirit-grammar(threadsafe/reusable): 3.81694
Vast increase, 3x faster xpressive is now. Also, how do you fix that rather bloody massive warning about double->int64 truncation? I also changed all int64_t to boost::long_long_type since they are the same thing anyway (on 32-bit at least?), as well as it being multi-platform unlike int64_t. My changed file is attached. Do not know if this is considered cheating now that xpressive is using some spirit now. ;-)
This is somewhat cheating. We've tuned the numeric parsers of Spirit with TMP tricks, loop unrolling, etc. Those are very finely tuned numeric parsers you see there that beats the fastest C code such as strtol and atoi. The following benchmarks reveal 2X+ speed against low level strtol and atoi (attached). I am getting:
atoi: 0.82528 [s] strtol: 0.792227 [s] int_: 0.358016 [s]
The first and second are the low-level C routines. The third is Spirit's int_ parser. I need not mention that the C routines only accept C strings while the Spirit int_ parser can accept any forward iterator. So, in a sense, we're comparing apples and oranges. But this goes to show that you can write highly optimized code in generic C++.
Slightly off-topic, but in order to emphasize what Joel said, here are a couple of benchmark results I published a couple of days ago related to output formatting: http://tinyurl.com/n4368t. Just an excerpt (Intel Core Duo(tm) Processor, 2.8GHz, 4GByte RAM, Intel 11.1/64Bit): Performance comparison for formatting a single double (all times in [s], 1000000 iterations): sprintf: 0.694 iostreams: 1.354 Boost.Format: 2.011 Karma double_: 0.218 (where double_ is the Spirit.Karma output generator for a default floating point format) Regards Hartmut