A howl on the wind…

A comparison of how many reallocations a worse case poorly coded use of realloc() does, compared to just using std::vector. 10000000 integers are added to the containers one-by-one. Clearly you would never abuse realloc() like this in real code, but it’s interesting nonetheless. Idea from sacrebleu at Freenode’s ##C++.

The full source is available in svn as a CMake project for easy cross-platform testing. Primary source vector-realloc.cpp

• Mac OS X: OS X 10.7.3, 2.3 GHz Core i5, 8 GiB RAM. XCode 4.3, clang++ 3.1 -std=c++0x -stdlib=libc++ -O3.
• Windows 7: 64 bit, 1.60GHz Core i7 Q720, 8 GiB RAM. MSVC++ 2010 _SECURE_SCL=0
• Linux: Arch: VirtualBox on the Windows machine, VT-x, Arch Linux, kernel 3.2.7-1-ARCH x86_64, 1 GiB RAM. GNU g++ 4.6.2 -std=c++0x -O3
• Linux: Fedora 10: Fedora 10, kernel 2.6.27 x86_64, 2.66GHz Xeon, 8 GiB RAM. GNU g++ 4.4.1 -O3

(Old version from 2010-04-02)

A performance comparison of the speed of operations on the various set implementations used in C++. There are 16383 unique elements across which 1000000 insert, lookup, iterate, and erase operations are performed.

The raw tick numbers are shown and table sorting is enabled so you can compare for yourself. Just be aware that the Mac OS X, Linux, and Windows numbers cannot be compared against each other.

The full source is available in svn as a CMake project for easy cross-platform testing.

Sources

• Containers:
  • std::set, std::unordered_set, boost::unordered_set – the usual general purpose suspects.
  • CG3::sorted_vector, std::vector based replacement for std::set. Suitable for small amounts of cheap objects, such as integers.
  • CG3::sorted_deque, rubbish version of sorted_vector.
  • CG3::interval_vector, specialized for storing integers that form intervals.
  • sti::sset, skip-list based std::set replacement. Wouldn’t compile with g++ or clang++.
• Ticks counted via cycle.h (local mirror)
• Source: CMake Project: benchmarks, primary source set.cpp

Continue Reading »

A performance benchmark of which include guard method is faster. Test times the compilation of a main.cpp that includes 10000 files 3 times each.

The tested methods are:

• #pragma once followed by #ifndef
• #ifndef followed by #pragma once
• Only #pragma once
• Only #ifndef
• External #ifndef

Sources for the test is at inc.tar.gz, but it’s just 5×10000 files.

The compilers are Microsoft Visual C++ 2010, GNU g++ 4.6.1, and LLVM clang++ 2.9.

Continue Reading »

(There is also a string-to-int performance test.)

A performance benchmark of which method is faster of converting an std::string to a double. The goal is ending up with a double of the value represented in an std::string.

The tested methods are:

• a hand-written naive loop
• atof()
• strtod()
• sscanf()
• boost::lexical_cast<double>()
• boost::spirit::qi::parse()
• std::stringstream
• std::stringstream, reusing the object

Source for the test is at speed-string-to-double.cpp with cycle.h.

The compilers are Microsoft Visual C++ 2010 with _SECURE_SCL disabled, GNU g++ 4.6.0, and LLVM clang++ from Arch.

Continue Reading »

A performance comparison of the speed of various ways to compare strings in C++. In this test, all comparisons are of not-equal strings.

Idea from #C++ on QuakeNet, where we always advocate using std::string over various char* functions. I wondered what, if any, the penalty for doing so was.

Sources

• Ticks counted via cycle.h (local mirror)
• Source: speed-string-compare.cpp

Things Tested

• a hand-written naive comparator loop; used as baseline
• string == string
• string == const char*
• strcmp(const char*, const char*) == 0
• strcmp(const char*, string.c_str()) == 0
• strcmp(string.c_str(), string.c_str()) == 0
• string.compare(string)
• string.compare(const char*)
• …and then the whole thing with different offsets.

Continue Reading »