I'm currently releasing version 0.6.1 (alpha 1) of FastFormat. Although 0.6 will contain a number of new additions, the first alpha release contains no functional changes. It's entirely about releasing some performance improvements that I've had in the bag for a long time, but keep overlooking.
The reason I'm doing so now is, in part, that there's been a thread on the FastFormat Help Forum concerning one potential user's assertion that FastFormat (and some of the STLSoft components upon which it relies) is not as quick as my previous claims have indicated. Thankfully, it was easy to perform some simple tests and ascertain that, so far, nothing's overtaken it in terms of performance. In one of the tests I added FastFormat (both write() and fmt()) and STLSoft's integer_to_string to an integer-to-string conversion test that included, amongst other things, Boost.Spirit.Karma. I'm pleased to report - with Visual C++ 9, at least (haven't had time to use other compilers yet) - that FastFormat holds its own, and with the new optimisations in 0.6 it is the fastest of the possible format components, including ~10% faster than Karma.
The only thing faster is the low-level stlsoft::integer_to_string() function that FastFormat uses internally, which is a good 30-40% faster than the rest. (Not that I'd advocate using it in application code, of course, since it's not so expressive, and requires pointer and buffer-length parameters.)
I owe thanks to the OP for causing me to look again and confirm FastFormat's performance advantages, and to release the long-awaited optimisations.