This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Performance of std::to_string
- From: Mikhail Maltsev <maltsevm at gmail dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Fri, 2 Jan 2015 19:17:24 +0300
- Subject: Performance of std::to_string
- Authentication-results: sourceware.org; auth=none
Hi, all.
Recently I came across several benchmarks of integer-to-string
conversion routines.
Here is a benchmark which includes (among others) std::to_string from
GCC 4.7.3 on x86_64 and sprintf (the version of glibc is not specified,
but it is probably 2.16 - the one which is used in author's OS repo):
http://zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html
The conclusion is: hand-crafted functions are almost an order of
magnitude faster.
Another interesting comparison:
http://www.codeproject.com/Articles/23198/C-String-Toolkit-StrTk-Tokenizer
(section "A Final Digression - Fast Integer To String Conversion")
mentions GCC 4.8.x and standard sprintf (libc version not specified).
I did not repeat the benchmark myself, but I noticed a couple of things
about current std::to_string implementation: __gnu_cxx::__to_xstring
uses std::vsnprintf/vswprintf. They are built-ins, but the current
implementation (gimple_fold_builtin_sprintf_chk) treats specially only
%s and %c format specifiers. So, in our case, the compiled code
involves a real call to vsnprintf. It is variadic (which means, slow
calling convention, and it does not get inlined). And the vsnprintf
itself will always parse the format string (which is a compile-time
constant). Such implementation simply cannot be fast.
I am aware of the requirements of [string.conversions] to
std::to_string. My question is: is it possible to somehow modify the
current implementation to leave it standard-compliant but to get rid of
an actual call to vsnprintf?
Maybe we could substitute vsnprintf in __to_xstring by another function
(provided that the behavior is identical)? Or even add support of
integer types to gimple_fold_builtin_sprintf_chk?
If I did not miss anything critical, I would like to try to implement
this enhancement (but I want to have some confidence, that it's worth
doing and and that my implementation won't just get thrown away because
of some obscure reasons).
P.S. Conversions of floating-point types are also interesting
but will require some knowledge about target's locale. Reverse
conversions, i.e. from strings to numbers would require even more.
--
Regards,
Mikhail Maltsev