So, basically, I was looking what I wrote previously for growing the "hunks" and "lines" arrays in the old patch code and I was copying the (admittedly odd) logic from there.

Just to write it out clearly, here is what I intended and why:

1. The smallest array I'll allocate is 8 items. I thought there should be a lower bound. Maybe for some larger objects this is not right.
2. When I need to grow, I double the size of the array. This seems reasonable.
3. Once the array hits 256 items, instead of doubling, I just add another 256. This is probably questionable, but with the patch "lines" array which can grow fairly large, I felt like I'd rather trade of more reallocations (every 256 items) instead of more wasted memory.

I really does come down to a tradeoff between how many reallocs to do versus how much memory we're willing to waste. This current logic makes an arbitrary cut off to waste at most 255 unused items. I'm open to a different rule. You could probably argue that second guessing a consistent 2x or 1.5x is not worth it for the extra complexity.

The first 15 values from the current code are:

    (8, 16, 32, 64, 128, 256, 512, 768, 1024, 1280, 1536, 1792, 2048, 2304, 2560)

Maybe `size_t new_size = (((a).size < 8) ? 8 : ((a).asize * 3 / 2));` is simpler. The first 15 values for that are:

    (8, 12, 18, 27,  40,  60,  90, 135,  202,  303,  454,  681, 1021, 1531, 2296)

which is a significantly slower growth curve (i.e. less wasted memory for small arrays) and grows faster at large sizes.

Simple 2x growth would give:

    (8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072)

which is pretty extreme compared to the other two, although obviously fewer reallocations.

After writing this all out, I lean towards the 1.5x growth with no upper limit. It seems easier to understand and will limit wasted memory.