The Generator interface is specialized for iteration and is often faster than indexing.
Using _initialize_to results in a ~10% speedup for Dictionary. For collections with more complex iteration state (such as search trees with O(log(n)) indexing), this leads to a complexity class improvement.
This requires a small change to the testsuite, because the generate() method of Defaulted*RangeReplaceableSlice called Array(self), which now leads to infinite recursion.
https://bugs.swift.org/browse/SR-610
...because it is apparently more efficient in some cases. Technically
we don't do this in ALL places, because it would be unfortunate if
the implementation of _successorInPlace() were self recursive :-)
At DaveA's suggestion, I took a mostly mechanical approach to this:
pointers and numeric types start using += 1, and indexes use
i = i.successor(). The index model is likely to be revised in
Swift 3 anyway, so micro-optimizing this code syntactically isn't
super important.
There is some performance concern of this patch, since some
in-place succesor operations are more efficient than
i = i.successor(). The one that seems particularly at issue is the
instance in the implementation of partition(), which I changed to
use i._successorInPlace(). If other instances lead to a perf issue,
they can be changed to use that as well.
The basic idea is to move the allocation of the buffer out of @_semantics("array.uninitialized") so that it can be inlined without inlining the semantics function (on high-level SIL).
This change in the stdlib also requires an adaption of the dead area elimination in DeadObjectElimination.
Otherwise it would just remove the semantics function but not the allocation and we would leak memory.
ArraySlice indices now map directly onto the collection it is slicing
and maintains that mapping even after mutations.
Before:
var a = Array(0..<10)
var s = a[5..<10]
s.indices // 0..<5
s[0] = 111
s // [111, 6, 7, 8, 9]
s.removeFirst()
s.indices // 1..<5
After:
var a = Array(0..<10)
var s = a[5..<10]
s.indices // 5..<10
s[5] = 99
s // [99, 6, 7, 8, 9]
s.removeFirst()
s.indices // 6..<10
- Refactor some of the internals of the buffer types to make it easier
to read and understand.
- Add Array, ArraySlice, and ContiguousArray to the test suite at the
RangeReplaceable test entry points, subjecting them to the same tests
as all of our collections.
- Update existing test expectations for the indexing changes.
rdar://problem/21866825
Swift SVN r30840
Replace the Lazy-based implementations with open-coded implementations based on the _UnsafePartiallyInitializedContiguousArrayBuffer builder from the previous commit, so that we have control over the early-exit flow when an error interrupts the operation.
Swift SVN r30794
This makes the code for efficiently initializing array buffers in-place more accessible to the rest of the standard library, and should also provide a performance boost for _copySequenceToNativeArrayBuffer, which had been implemented as a naive append loop, by handling reallocating the buffer when necessary when initializing from a sequence that underestimates its count.
Swift SVN r30793
This covers:
- Lifetime-extending wrappers, like withExtendedLifetime, withCString, and withUnsafe*Pointer
- 'map' and friends on Optional
- 'indexOf'
A few APIs I haven't gotten to yet in this first pass:
- Autoclosure APIs, like assert, &&, etc.
- the 'isOrderedBefore' predicate for sorting APIs. The sorting implementation does some microoptimizations with 'inout' closures that violate rethrows checking.
- Strict 'map', 'filter', and friends on CollectionType. These need some plumbing in Lazy to be able to thread a Result-forming transformation through.
This version of the patch updates some protocol customization implementations that I missed the first time around, and includes the tests I forgot to add in the previous iteration.
Swift SVN r30790
FlattenCollection used to evaluate the closure three times per element.
That's acceptable from the technical standpoint, given its lazy
semantics, but not acceptable in practice. This commit fixes it to only
evaluate it two times when it is converted into an array.
This commit also improves tests. The new checks used to fail before the
standard library was fixed.
But there are larger issues with FlattenCollection -- it does not model
CollectionType properly. See next commit.
Swift SVN r30616
This covers:
- Lifetime-extending wrappers, like withExtendedLifetime, withCString, and withUnsafe*Pointer
- 'map' and friends on Optional
- 'indexOf'
A few APIs I haven't gotten to yet in this first pass:
- Autoclosure APIs, like assert, &&, etc.
- the 'isOrderedBefore' predicate for sorting APIs. The sorting implementation does some microoptimizations with 'inout' closures that violate rethrows checking.
- Strict 'map', 'filter', and friends on CollectionType. These need some plumbing in Lazy to be able to thread a Result-forming transformation through.
Swift SVN r30597
Not only it does not achieve what the comment says (_storage has the
type _ContiguousArrayStorageBase), but optimizations that would break
semantics of this code would be invalid anyway.
Swift SVN r29056
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
