Tino Didriksin published yet another speed comparison of different ways to convert an integer into a string (see his blog A howl on the Wind…). And again, Karma turns out to be the leader of the pack by being upto 10 times faster than the other tested methods. This nicely supports our own measurements (see here). Thanks Tino!

Here are my results comparing Karma to Strtk using the test mentioned, I’ve tried this on a dual and quad core system and I can’t figure out why karma has such a large stddev – I’ve made sure the system idle no other processes running etc.

thanks for the links! Joel and I are in contact with the author of the strtk library and we pointed out to him that he is using the string class in a way explicitly prohibited by the Standard (he is modifying the buffer content returned by string::c_str()), which gives the speed advantage over Karma he is seeing. I believe, if he changes his code not to use undefined behavior it will be a lot slower as he needs to maintain his own buffers instead. The author promised to change his code and to rerun the benchmarks, which has not happened yet.

Michael S,
I believe the String Toolkit library as it is now does not contain any of the “undefined behaviours” that Hartmut suggests with regards to the results found on the CodeProject article. I’m currently awaiting on Hartmut to provide an exact comment about the nature of the undefined behaviour as the library stands rather than a general comment or assumption.

As for the results on the CodeProject article – all tests are rerun and results updated as new changes are made to the library.

Its true that the Tino tests are more than a bit weird, as in timing individual occurrences of very simple events running on a multithreaded OS running atop of a multiple execution pipe-line architecture will continuously add slight errors to the results, however it is does give a general idea of relative performance – which is quite useful.

One typical suggestion that Tino could have used from stats-101, when attempting to use such timing values to compute an average, its very common to remove the top x% and bottom x% of values, this removes most of the outliers, which in turn should reduce the overall variance of the mean.

As expected, the Format API does pretty well, in particular against the likes of IOStreams and lexical_cast. But the best performance is to be had from the Write API, which actually out-performs all other options, by ~10%. The results are included at the bottom of this post, if you’re interested.

Please note that the results are based on the latest FastFormat release (0.6.1-alpha-1), which is released today (not entirely coincidentally). I only did the “reuse string” test, as I couldn’t see anything to be gained by the “new string” test.

Hope you find it useful. I’d be interested to know whether its omission from the test was because you’d not heard of it, or for another reason. (No drama either way, just interested.)

Am happy to. I’ll be including it – or an equivalent (as I don’t know what the copyright situation is) – in the next 0.6 alpha, hopefully at the coming weekend. (I’ll also include another test, based on Karma’s test program.)

For now, I’ll just publish the blocks of code that I added to include the two FastFormat APIs. Please note that this was with VC++ 9 (32-bit) windows, compiled with:

(The implicit_link.cpp file just does a #include <fastformat/implicit_link.h>, btw)

I make no claims to how it might all perform with other compilers and other platforms, but previous research on its performance show a pretty consistent relationship between them (with the singular exception that IOStreams does heaps better on Linux than Windows).

Also, I should note that there are FF facilities for eeking out better performance, by using different “sinks” (such as the char_buffer_sink and the c_string_sink). But the default sink accepts anything structurally-conformant to std::string (or std::wstring in widestring builds).

If you need any help with getting set up, or have any other questions about FastFormat, feel free to post questions on the FastFormat Help Forum.

Here goes with the code (making no promises for how the angle brackets go … ;-):