The performance of Boost.Convert depends entirely on the performance of the converter deployed. A few converters have been tested for string conversions to basic types and to a user-defined type.
In turn, the relative and absolute performance of every particular converter
depends on the platform, the compiler used and the particular implementation
of the underlying conversion component (
etc.). Consequently, the results below are only an approximate indication
of relative performance of the mentioned converters
on the tested platforms.
Compiled with gcc-4.8.2 on 32-bit Ubuntu 14.04 tests produced the following relative results:
str-to-int: spirit/strtol/lcast/scanf/stream= 1.31/ 2.15/ 3.41/ 6.72/ 7.24 seconds. str-to-lng: spirit/strtol/lcast/scanf/stream= 1.24/ 2.39/ 4.18/ 6.63/ 7.20 seconds. str-to-dbl: spirit/strtol/lcast/scanf/stream= 1.45/ 4.07/ 5.19/ 11.13/ 14.47 seconds. int-to-str: spirit/strtol/lcast/prntf/stream= 7.49/ 6.48/ 8.01/ 11.76/ 9.31 seconds. lng-to-str: spirit/strtol/lcast/prntf/stream= 7.34/ 6.89/ 8.43/ 11.55/ 9.32 seconds. dbl-to-str: spirit/strtol/lcast/prntf/stream= 14.13/ 13.56/ 50.03/ 46.25/ 44.72 seconds.
Compiled with gcc-4.6.3 on 64-bit Ubuntu 12.04 tests produced the following relative results:
str-to-int: spirit/strtol/lcast/scanf/stream= 0.29/ 0.47/ 1.14/ 2.75/ 3.15 seconds. str-to-dbl: spirit/strtol/lcast/scanf/stream= 0.40/ 1.44/ 1.70/ 4.32/ 5.59 seconds. int-to-str: spirit/strtol/lcast/prntf/stream= 1.75/ 1.53/ 2.06/ 3.34/ 2.73 seconds. dbl-to-str: spirit/strtol/lcast/prntf/stream= 5.64/ 3.00/ 17.89/ 14.24/ 13.67 seconds.
Based on the results, all things considered, I tend to conclude that there is no clear winner:
double) conversions. So, it might be a good candidate for the tasks predominantly doing that kind of conversions (with Spirit.Qi conversion-related limitations in mind); Spirit.Karma's to-string performance did not seem as impressive;
std::iostream-based converter was comparatively slow. Still, given its maturity, availability and formatting support, it might be an option to consider if conversion performance is not your primary concern;
strtol-inspired converter was reasonably fast and with formatting support might be an attractive all-rounder. It should be noted that it is nowhere as mature as
boost::cnv::stream. So, bugs are to be expected.
For user-defined types
were tested with the following relative results:
str-to-user-type: lcast/stream/strtol=1.14/0.59/0.23 seconds. user-type-to-str: lcast/stream/strtol=1.97/0.39/0.24 seconds.
To provide string-to-user-type and user-type-to-string
conversions the first two deploy the same standard
in these tests. The results probably reflect different underlying designs.
Namely, the standard Boost.Convert deployment pattern
is to create a converter or converters once and then re-use them.
boost::lexical_cast, on the other hand, due to
its design, creates and then destroys a
instance every time the function is called and the
boost::lexical_cast performance table
indicates that the "std::stringstream with construction"
operation is considerably more expensive compared to "std::stringstream
support for user types has been implemented similarly but without the
overhead. That resulted in the best out-of-three performance results.
Based on the performance data, I tend to conclude that, given type-safety and benefits provided by the Boost.Convert framework, it (with appropriate converters) should probably be the first choice for conversion-related tasks.