This is mostly just a renaming of _SwiftNativeNSArray, except that we
want to add another NSArray subclass for verbatim-bridged elements, so
we want a common base class. _SwiftNativeNSArray is the name of that
new base class, to parallel the other _SwiftNativeNSXXX classes.
Swift SVN r22913
The buffer stored in a _ContiguousArrayBuffer<T> is not always
_ContiguousArrayStorage<T>. It might in fact be the special empty
buffer class.
Swift SVN r22835
The buffer stored in a _ContiguousArrayBuffer<T> is not always
_ContiguousArrayStorage<T>. It might in fact be the special empty
buffer class.
Swift SVN r22823
Buffer identity is only used by tests. The switch to an identity
representation that accounts for the buffer length was actually
incorrect for the way many tests used it.
Swift SVN r22771
Fixes rdar://problem/18646425
Running the test uncovered avoidable inefficiencies in Array copying, so
dispatch of _copyToNativeArrayBuffer was revamped. It's reasonable to
expect some speedups from this.
Also, the internal Array API requestNativeBuffer was highly error prone
when the source was a Slice, because it could return an array buffer
that represented more than the entire slice. That capability was
probably used for optimization once, but is no longer, and the error
prone API probably caused bugs, so it was reformed.
Swift SVN r22746
They were never really useful to users, because their APIs were
insufficiently public. They have been replaced with a single class,
ManagedBuffer<Value,Element>, which is really designed for user
consumption.
Swift SVN r22636
Now that <rdar://problem/18540783> is fixed, we can stop allocating the
empty array buffer dynamically and go back to using the one that is
statically laid out in GlobalObjects.cpp, thereby avoiding the
atomic instructions required to make it threadsafe.
Swift SVN r22545
NFC, and no significant performance change expected. This is part one
of a move to eliminate nil checks from the array implementation.
Swift SVN r22526
NFC, and no significant performance change expected. This is part one
of a move to eliminate nil checks from the array implementation.
Swift SVN r22495
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.
Swift SVN r22408
A collection whose count changes between traversals could cause a memory
safety problem, as we would measure the collection in one pass and
assume that it was the same length when actually initializing array
elements. Fix that by always using the initial measurement, which
corresponds exactly to allocated memory. If the collection wants to
trap because we've gone past its new bounds, that's fine. If it
doesn't, at least we haven't done anything unsafe.
Swift SVN r22152
Array did not initialize fast enumeration state if it was empty.
Surprisingly, this did not break code that is generated by Clang
currently. (But as far as I understand fast enumeration, it may abort
the program because mutation pointer is null.)
Swift SVN r21940
When creating an array from a SequenceType not statically known to be a
CollectionType, don't neglect to pre-allocate based on its
underestimated count.
Swift SVN r21829
This should allow us to better optimize repeated push/pop benchmarks.
I didn't notice a performance change at the time I did this. I'm just
putting it in as a hopefully obvious drive-by fix.
Swift SVN r21429
Replace the true/maybe state that Builtin.canBeClass was returning by a
tri-state (yes, no, maybe) allowing the optimizer to use the definite no
answer. This removes the need of the sizeof check that we had in
isClassOrObjCExistential. It also removes the need to CSE this function since
in most cases we will be able to instantiate canBeClass to yes or no (vs maybe)
at compile time.
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
ClassArrayGetter```````,``988.00````,``337.00```,``644.00``,````````191.7%
DeltaBlue``````````````,``2429.00```,``1927.00``,``460.00``,````````23.9%
Dictionary`````````````,``1374.00```,``1231.00``,``129.00``,````````10.9%
Havlak`````````````````,``1079.00```,``911.00```,``124.00``,````````13.7%
Rectangles`````````````,``924.00````,``541.00```,``379.00``,````````70.1%
radar://16823238
Swift SVN r21331
This also reverts the commit "stdlib: Don't check for overflow in subscript accesses to
ContigousArrayBuffer" as removing the overflow check on all unsafe pointers has
the same effect.
Swift SVN r21220
We overflow checked the mulitplication in "a + sizeof(T) * i". This is not
necessary for ContingousArrayBuffer because this overflow check has happened
when we compute the size of the array during allocation of a native swift array
or a NSArray.
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
Memset`````````````````,``1184.00```,``487.00```,``698.00``,````````143.9%
QuickSort``````````````,``1299.00```,``1458.00``,``178.00``,````````-12.2%
SelectionSort``````````,``1027.00```,``814.00```,``213.00``,````````26.2%
StdlibSort`````````````,``1718.00```,``1587.00``,``127.00``,````````8.0%
Walsh``````````````````,``1160.00```,``1076.00``,``86.00```,````````8.1%
XorLoop````````````````,``1248.00```,``884.00```,``369.00``,````````42.0%
The regression in quicksort is noise - i looked at the LLVM IR and the only
thing different in the graph is that we have removed the mulitplication with
overflow check (that is - we should be running faster). Same thing looking at
the assembly.
XorLoop and Memset speed up because we are now able to vectorize those loops.
Swift SVN r21218
To limit user confusion when using conditional expressions of type Bool?, we've decided to remove the BooleanType (aka "LogicValue") conformance from optional types. (If users would like to use an expression of type Bool? as a conditional, they'll need to check against nil.)
Note: This change effectively regresses the "case is" pattern over types, since it currently demands a BooleanType conformance. I've filed rdar://problem/17791533 to track reinstating it if necessary.
Swift SVN r20637
In answering a forum post I noiced that I wanted this and it was
missing.
Also, extensive comments
Also, rename the length: init parameter to count:. When writing the
comments for the init function it became painfully clear why we use
"count" is better than "length" especially around pointers and memory:
the former is much less easy to mistake for "length in bytes". Plus
it's consistent with the new ".count" property
Swift SVN r20609
Ultimately this gets to HeapBuffer which checks the index is in range by separately checking whether the storage is nil, then the index is less than the count
Swift SVN r20363
Arrays of non-verbatim-bridged types (such as Int, and today's String)
are converted to Objective-C lazily, with the objects created due to
element conversion being autoreleased when necessary.
Fixes <rdar://problem/17360154>
Note: test/SIL/Parser/array_roundtrip.swift was XFAIL'd;
see <rdar://problem/17758203>
Swift SVN r20293
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
