Hey Joel,

couple of problems with this approach: (a) it wouldn't be any different performance-wise from allowing multiple blocks (these're chained together with the container just keeping track of the 'head' of the unused block list). (b) Since there are implementation-defined limits to maximum block sizes (specifically, constrained by the skipfield type, which determines the maximum number of erased elements which can be skipped), multiple unused blocks are inevitable

for any reserve size larger than the maximum block size.

Just to be clear about what I meant with reserve in the previous version of colony's implementation, it only would reserve one block if it was the first block in the colony, and would reallocate existing elements to that block if some already existed - basically it worked fine if the colony was empty but was otherwise problematic.

But thanks for that thought, regardless.

Regards benchmark results, cross-compiler results show 2% overall performance drop with reserve enabled in MSVC2019 (with no substantial massive per-test differences like GCC9), no difference in clang, GCC8 is consistently a 1-2% overall performance increase with reserve enabled.

Overall performance difference between GCC8 and GCC9 with reserve enabled is -4%, not mentioning the -11% difference for some individual tests, so I'm going to go ahead and call "compiler bug" on that one, report it to GCC and see where that goes.

In terms of allowing/disallowing reserve at this point, I'm unsure which direction to go. I will completely finish the with-reserve implementation including the necessary changes to other functions, then re-benchmark at that point. If anyone has some answers/perspective on my previous questions, I'd appreciate it at this point.

Thanks

Matt