This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Performance of std::to_string


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]