Naïve `_update` strategy could be suboptimal.

[dabrahams]

The problem is that withUnsafeMutableBufferPointer forces a copy if the storage is not uniquely referenced. If you are going to then rewrite/move a significant number of elements, the original copies are wasted effort, which could be bad for locality. What you really want in those cases is to construct the new buffer in its final form in-situ. This is just something to consider/benchmark as you look to further optimize. Starting with the current strategy certainly makes sense.

[lorentey]

Oh yes yes! Bulk mutations making a copy of items only to immediately throw most of them away has been frustrating me for years.

Ideally we'd have three code paths for most mutation operations:

storage is uniquely held	it has enough room	strategy
yes	yes	in-place mutation of existing storage
yes	no	populate new storage by moving items
no	any	populate new storage by copying items

(With a potential middle ground where the second strategy (moving items) is rolled into the third.)

Currently, mutation operations often have just one implementation: in-place mutation. The uniqueness/capacity preconditions are ensured up front in a uniform (but wasteful) way. This keeps the happy path fast, but it makes slow paths slower than necessary.

There are two excuses for why we do it like that:

1. I worry about blowing up code size, especially as we expect these operations to get specialized for every type parameter
2. I worry about introducing bugs, as I don't really have a good way to systematically test the newly introduced code paths

(Well, these two, and the fact that people haven't much complained about mutation performance for non-uniquely held collections...)

FWIW, I'm working on replacing the _read/_update pattern with a new library construct; this provides a good opportunity to refactor things along these lines!