C++ performance myths debunked

[Benjamin Binford]

On Mon, 12 Aug 2002 06:32:00 -0400, Mark Charsley wrote:

> In article <3d4acdcc.18746140 at news.t-online.de>, gerson.kurz at t-online.de 
> (Gerson Kurz) wrote:
> 
>> Download the libraries from over at www.boost.org. Compile a sample
>> program (with VC6), get 31 warnings like this (I'm not making this up,
>> and yes, it is *one* single warning):
> 
> <SNIP>
> 
>> So much for C++ syntax.
> 
> It's more to do with MS's compiler than C++.
> 
I just tried it out with gcc 3.1, which is supposed to be pretty decent
for c++. str_tok_opt is the str_tok version, test_opt is the
boost version, and test.py is obviously the python version. 200,000
iterations were done for each one.
ben at gryphon perf_test $ time ./str_tok_opt

real	0m0.138s
user	0m0.136s
sys	0m0.002s
ben at gryphon perf_test $ time ./test_opt

real	0m6.496s
user	0m6.456s
sys	0m0.041s
ben at gryphon perf_test $ time python test.py

real	0m2.799s
user	0m2.786s
sys	0m0.014s
ben at gryphon perf_test $ 

I originally suspected that the boost code was spending most of its time
in memory allocation/deallocation in the inner loop, so I was pretty
surprised to see that this was not so when I profiled it. It spent most of
its time in various boost functions (including 9.2 million calls to
extract_cie_info for almost a full 1.5 seconds) I think in this instance
the boost library has some pretty hefty performance issues. Even for
phenominally large strings you're better off making a copy and running
str_tok on it c++ized as a tokenizer container and set of iterators (ie
mirror the structure of the boost library and rip out the guts)