PLF Library - plf::hive vs boost::hub benchmarks - main page

Test machine setup

The test setup is an an Intel i3-8100 (Coffee lake core), 8GB ram.
All benchmarks run in windows safe mode in order to avoid latency spikes from networking, display drivers and services etc. All benchmarks built at x64 with default O2 optimisation levels, without CPU-specific extensions (eg. -march=native). The versions of hub and hive used respectively are those available publicly via their github repos (https://github.com/mattreecebentley/plf_hive and https://github.com/joaquintides/hub) on 18/05/2026, though I had to edit hub's memory() function as it was not adding sizeof(*this).

The source code for the benchmarks is here. Full spreadsheet data is on each compiler's page.

Results, graphs and averages

MSVC results are here.

GCC results are here.

Clang results are here.

For full explanations of each benchmark and the methodology used, see the general colony benchmark page here or this blog post.

Overall summary

Performance summaries vary across compilers and are at the bottom of each compiler's page. It's best to consult each page individually to get a clearer picture, particularly from the graphs. However general performance conclusions follow. Note that benchmark results may vary between CPUs (but probably not by that much for consumer ones at least).

Insert is slower for hive under msvc except for large types, slower for clang except for large types, and slower for gcc except for large numbers of large types.
Erase is faster for hub.
Iteration is generally faster across compilers for hive, however it is slower for 64-bit types under clang, and there is variation based on the number of elements.
Isolated micro-benchmarks of insert, erase and iteration, are not sufficient to measure how a hive or hive-like container will perform during iteration over time as erasures and reserved blocks stack up, as the handling of the latter differs significantly between containers. The proof for this can be seen in the msvc results, which have worse insertion, erasure and post-erasure iteration performance for the 48-byte ("small struct") isolated benchmarks, but are faster than hub in the general use (unordered modification) tests, which also store 48-byte structs and perform insertion, erasure and iteration in the same container instance over time. Only at the highest insert/erase-to-iteration ratio (10% of container size inserted/erased per-iteration) does hub perform better. This is not an anomoly; the same pattern can be seen in clang and gcc, where insert/erase isolated benchmarks are slower in hive with post-erasure iteration only 1% faster than hub, but hive is 8% faster for all the lower churn ratios in the unordered modification benchmarks.
General use (unordered modification) tests are always faster for hive with low modification (ie. up to 10% of all elements being inserted/erased per 3600 iterations),
for high modification hive is faster at 1% elements inserted/erased per-iteration except on clang, at 5% hub is faster except for msvc, and at 10% hub is always faster. Given the insert/erase/insertion results above we can expect that results will skew more in hub's favour for smaller types in this same benchmark (48-byte type used), and more in hive's favour for larger types.
Engine emulation (referencer) tests are faster for hub till container size reaches around 2500 elements, then becomes massively faster for hive from that point on.
Comparitive performance (ie. optimisation) tends be slightly better for hive under MSVC, less so for GCC and even less under Clang.
According to Joaquin's benchmarks hive seems to be a lot faster than hub for 32-bit executables, but I haven't benchmarked this.
Memory use of hub varies between 96% and 50% of the usage of hive (see spreadsheets for each compiler).
I have not benchmarked visitation, may do so at some point if I implement it in colony, or as a non-std::-compliant extension for plf::hive.