[WIP] [stdlib] Improve performance of Array initialization with known capacity

[ahoppen]

Currently the initialisation of an array with a known number of elements has two performance problems:

• An _EmptyArrayStorage is allocated and directly released once the first element is added (rdar://41214707)
• For each append, _ContiguousArrayStorage is retained and released when append is exited. Since the Array already holds a reference to its storage this shouldn't be necessary.

The fix

I've optimised the Collection.map and Sequence.map to directly allocate the required storage and write to its memory directly by calling to _allocateUninitialized instead of ContiguousArray.init().

[ahoppen]

@swift-ci Please smoke test

[airspeedswift]

This doesn't seem like the right solution. I was under the impression that there was a single _EmptyArrayStorage instance singleton (here: https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift#L68) that would be used, so it shouldn't be causing allocations every time. If that's not working (or if I'm missing something and it doesn't work that way) maybe there's a fundamental fix, because this problem will also affect user code and outside the std lib you don't have this option.

[ahoppen]

Ah, it might be that we just retain the Empty Array Storage instance. It was mostly that `_swift_release_` of `_EmptyArrayStorage` and `ContiguousArrayStorage` was showing up as a major bottleneck in Instruments. Why don't you think this is the right solution (I haven't looked into the test failure yet)? And would you know of a different way to mitigate the issue?

[natecook1000]

Can you switch count to n here, in case a collection is super broken and returns a different count here compared to up above? Otherwise we might write past the buffer in the loop below.

[ahoppen]

@swift-ci Please smoke test

[ahoppen]

@swift-ci Please smoke test

[airspeedswift]

Why don't you think this is the right solution (I haven't looked into the test failure yet)? And would you know of a different way to mitigate the issue?

Like I said, this is a narrow fix that will only work within the standard library for a general problem that affects all users. We need to figure out a way of solving it for everyone not just paper over it. Either in code inside the library (find some way that starting with an empty array is free) or via changing the API (i.e. allowing one-shot create-and-reserve).

Once we have that solution, we can consider a localized temporary fix like this but we need to do it in that order.

[ahoppen]

@swift-ci Please build toolchain

[airspeedswift]

So #17389 should provide what's needed – the ability to init with a capacity. This needs evolution approval, but maybe we can implement it with underscores and use it in the mean-time. In fact, it would be interesting to see if it yields a performance benefit to do use the full proposal to implement map and similar functions.

[ahoppen]

This seems to be exactly what I need. Closing this and I'll wait for @natecook1000's implementation.

[airspeedswift]

cc @natecook1000 – looks like this would be a great candidate for proving out the changes you're proposing for one shot initialization. It might even make sense to land underscored implementations in master and then use them to implement map, wdyt?