Measuring Boost.MultiIndex Performance

Although I generally view most of Boost as bloatware that suffers from feature-creep, Boost MultiIndex provides a simple, STL-like container with different views, allowing fast data acess with multiple indexers.

Although the Boost documentation claims dramatic performance improvements for the multi_index container, relative to manually-maintaining multiple views, the tests were run with archaic compilers (GCC 3.4.5) and operating systems (Windows 2000). Inspired by this post, I decided to benchmark MultiIndex’s performance using Boost’s performance tests.

Methods

All tests were run with the following parameters, for GCC 6.3, Clang 3.8, and Fedora MinGW.

Parameter Value


CPU i7-6560U, 2.20GHz
OS Fedora 25
RAM 16 GB
Flags -O3
Wine Wine-2.2 (Staging)

Results

1-Ordered Index
--------------------------------
2-Ordered Indexes
--------------------------------
3-Ordered Indexes
--------------------------------
1-Sequenced Index
--------------------------------
1-Ordered, 1-Sequenced Index
--------------------------------
2-Ordered, 1-Sequenced Indexes

Conclusion

In general, the hashmap implementations (sequenced) of Boost MultiIndex are superior to the STL containers, both in memory (data not shown) and iteration time. Similarly, using MinGW, the ordered MultiIndex containers outperform their STL counterparts for both memory and iteration speed. However, with Clang and GCC, although the MultiIndex containers use less memory than their ordered STL counterparts, they have worse iteration times, and this performance gap increases with container size. Overall, MultiIndex is an excellent drop-in replacement for unordered containers, but suffers severe performance defects for ordered index iteration.

This gap between the ordered and unordered index iteration is trouble, since Boost’s documentation states precisely the opposite.

comments powered by Disqus