31.8. Performance

Since the motivation for exposing ourselves to the RVL dangers inherent in these different conversion solutions is efficiency, it behooves us to quantify the potential payoffs so that we can judge whether it's worth all the inconvenience and complexity. In particular we're keen to discover whether the increases in usability in the later solutions has resulted in a significant loss of efficiency over Solution 1.

Since Solution 3 is a Dodo, I'm not including that in the performance test. Solutions 1, 2, 4, and 5 are compared with the standard C library function sprintf(), the popular C library extension function itoa(), and the int_to_string_instance() function described in the last section. These seven conversion mechanisms were tested for five popular Win32 compilers, all optimized for speed (see Appendix A). For each mechanism, 10 million 32-bit signed integer values are converted to string form. This is done twice, and the time of the second iteration is reported.^[12] The results are shown in Table 31.2.

^[12] All tests were carried out on a 2GHz 512MB Pentium IV machine in a single session with no other busy processes.

Table 31.2.

	CodeWarrior	Digital Mars	GCC	Intel	Visual C++ 7.1	Average
Sprintf	100.0%	100.0%	100.0%	100.0%	100.0%	100.0%
itoa	67.8%	44.8%	27.5%	26.8%	28.1%	39.0%
Solution 1	24.7%	18.8%	12.6%	12.0%	29.4%	19.5%
Solution 2	26.8%	20.4%	14.1%	12.7%	29.0%	20.6%
Solution 4	24.5%	19.6%	12.7%	11.8%	29.5%	19.6%
Solution 5	28.5%	18.9%	12.6%	11.8%	29.5%	20.3%
int_to_string_instance	124.4%	37.4%	42.2%	28.1%	43.2%	55.1%

The results clearly show that the four custom conversion mechanisms represent a significant net performance win over sprintf() and itoa() for each of the compilers and their standard libraries, except for Visual C++ 7.1 where they are merely roughly on a par with its implementation of itoa(). Given that the Intel test was conducted with the Visual C++ 7.1 run time library, it's clear that the custom solutions do offer a significant performance advantage when paired with a compiler that is able to provide high levels of template optimisation. On average, the custom solutions are twice as fast as itoa(), and five times faster than sprintf().

The four custom solutions provide virtually identical performance, so the choice between them can be made on the issues of ease-of-use, convenience, and the various strengths and weaknesses of their susceptibilities to RVL.

There's one last thing I should point out, though it may cost me some stars on my C++ good behavior chart. The performance for the value (std::string) returning option doesn't exactly set the world alight. In most cases it outperforms sprintf(), but despite the helping hand of being implemented in terms of integer_to_string(), the cost of the single memory allocation^[13] and strcpy() involved in creating the return value means that this option does not fair well with respect to the custom solutions.

^[13] This assumes that all the compilers tested apply RVO in the integer_to_string_instance<>() function, which we saw that these five were able to do in Chapter 12.