Performance

| Home | Libraries | People | FAQ | More

## Performance

### Converters Compared

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 (`std::stream`, `printf`, Boost.Spirit, 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:

- the Spirit.Qi-based converter was the fastest for string to basic (`int`, `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;
- the `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;
- the `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::lexical_cast` and `boost::cnv::stream`. So, bugs are to be expected.

For user-defined types `cnv::lexical_cast`, `cnv::cstream` and `cnv::strtol` 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 `std::iostream` library. However, `boost::cnv::cstream` considerably outperforms `boost::lexical_cast` 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 `std::stream` 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 without construction".

`boost::cnv::strtol` support for user types has been implemented similarly but without the `std::stream`-related 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.