Just an update regarding the use or presence of reserve() in colony,
as discussed in the june meeting, reserve could be useful in the sense of
(a) moving allocation cost to non-hot-loop areas of code and
(b) preventing the establishment of many smaller-sized element memory
blocks during singular insertions, if the approximate number of overall
insertions is known in advance. This in turn increases cache locality for
elements.

The current reserve function only allows for the creation of one memory
block, which is of course not suitable for the end specification,
as the size of memory blocks is limited by various factors and a reserve
function which does not necessarily reserve the capacity requested is not a
good fit for the C++ standard.

As mentioned in the meeting my previous tests of creating a version which
allowed for multiple empty memory blocks "in storage" created untenable
performance detriments, to the tune of 2% on average.
In addition such a function necessitates another function to free unused
memory blocks without reallocating elements (as opposed to shrink_to_fit
which reallocates).

Anyway, I thought I'd try again and see whether I could come up with a
better solution this time without any performance advantages.
I didn't look at the old code, so as to obviate any chance of me recreating
the same possibly-slower-performing pattern.

Unfortunately the same results were found - specifically, 2% slower on
average for both my general use and 'referencer' (game-scenario) benchmarks.
But most importantly, in the key areas where colony overtakes all other
containers/container-adaptations in terms of performance (general use with
high ratios of insert/erase to iteration), colony became 10-11% slower. I
believe this was also the case the last time I tried this. This is
untenable and reserve will be removed from future versions of the
specification.
I tried many different approaches, comparing their results but no amount of
optimization would shift this figure significantly.

I still have a few more things to implement and test before I release the
next version of the specification, but it shouldn't be too far off.

In terms of the useful aspects of reserve as mentioned above, these can be
replicated by:
(a) using allocators with colony to move the allocation costs away from any
hot loops
(b) changing the minimum element memory block capacity sizes before
insertion to guarantee the capacity of the first block allocated.

While reserve would've been useful, I believe it's cost in this case
outweighs its benefits.
In case anyone's interested, both the highest-performing version of the
with-reserve() colony.h, and the spreadsheet of the general use performance
results are attached. The implementation lacks re-use of memory blocks in
the range-insert/fill-insert/initializer-list-insert/splice functions, and
probably a few other functions that weren't critical for benchmarking, so
is not usable in production.

Thanks-
Matt