As Emaer said, memory allocation is relatively slow on the heap, so we reserve multiple elements at a time. This is pretty standard with dynamically resizing arrays- ie in the standard library, gcc implements vectors with a 1.5x allocation (so 3->4, 6->9, 10->15, 1000->1500) iirc.
Bringing us back to your third array, the reason it’s so much bigger is because it allocates for 4 elements.
By default (ignoring some optimizations), whenever the default sized allocator runs out of space, it will allocate according to this calculation:
const SIZE_T FirstGrow = 4;
const SIZE_T ConstantGrow = 16;
SIZE_T Grow = FirstGrow; // this is the amount for the first alloc
if (!bArrayIsEmpty)
{
Grow = SIZE_T(NumElements) + 3 * SIZE_T(NumElements) / 8 + ConstantGrow;
}
Since this only happens on a resize, you can avoid this by explicitly reserving exactly how much you need, which is a good practice I see you already know of given the Reserve.
I do want to point out that this is actually up to the individual developer in most cases, and the default behavior for most of the remove functions is to shrink the array so it doesn’t hold onto that memory. Sometimes this is a bool, but most of the time it’s an EAllowShrinking.