A brief-ish (author-consulted) guide for when to use boost::hub over plf::hive/colony, with benchmarks

std::hive/plf::hive author here, I recently found out about boost::hub via a friend, ran my own benchmarks, and contacted the author, Joaquin.

We've been talking over the past week and while we have some disagreements (more here: https://plflib.org/blog.htm#hive\_vs\_hub), we generally agree on the following and we've learned a bit from each other as well.

Please bear in mind that the following assumptions only apply to the current implementations of plf::hive and boost::hub, not future implementations nor other std::hive implementations.

As an example, myself and another have been working on a memory-reduced implementation of hive since august '25 (\~1.2bits skipfield per element average) and we dont know what the performance results will be for that yet.

That aside, the following is true (when I say 'hive' below I mean plf::hive, and same conclusions apply for plf::colony since it's largely the same code):

* Hub is generally faster overall for smaller types, for very large types hive is typically better.

* Insert is generally faster for hub except for large types.

* Erase is faster for hub.

* Results vary a little by compiler, but in tests which measure the effect of insertion and erasure on iteration over time using 48-byte structs, hive is faster except for high churn ratios. Specifically hub tends to be better once the ratio is around or above a number of elements equal to 5% of the container size being inserted/erased for every single iteration pass over all elements. However for very small elements the ratio will likely shift downward (in hub's favour) and for very large elements the ratio will likely shift upwards (in hive's favour).

* get_iterator() performs worse when maximum block capacities are smaller, as there are more blocks to check before the pointer location is found, so hub performs much worse than hive (when default-or-larger max block sizes are used with hive) here. However the results would be the same in hive if a user were to limit the block capacities to 64-elements max themselves.

* Sorting is faster with hub except for large numbers of large types - we both need to do some work here.

* According to Joaquin's benchmarks hive seems to be a lot faster than hub for 32-bit executables, but I haven't benchmarked this.

I haven't mentioned visitation yet, but it's cool! It's a technique which can be applied to any semi-contiguous container including deques, unrolled lists like plf::list, colony, segmented vectors and potentially as a (non-compliant) extension for hive. Basically it's iteration + pre-fetching, which only the container can do because it knows when the next block begins during iteration. It's not something you want the container to do during iteration normally because it doesn't know how the user is using the container at that point.

However, it is limiting in how you can use it - basically it's good if you want to do the same thing to a range of elements, but it doesn't work with the standard library routines such as rangesv3, because that all takes iterators. You also need to be careful with it if your code or libraries you use do pre-fetching internally.

If you can use the visit* techniques in your particular use-case may shift the balance of the above in hub's favour, except for large elements, where insertion performance can be better with hive, depending on the compiler. But I will probably implement the same techniques myself soon, for colony.

From my benchmarks across clang, gcc and msvc (https://plflib.org/benchmarks\_hive\_vs\_hub.htm) I'll also add the following conclusions, though will likely be some variance based on CPU:

* Isolated 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, because handling of the latter differs