Jira: SR-88
Changes:
- Removed stdlib type conformances to _Reflectable
- Conformed stdlib types to CustomReflectable, CustomPlaygroundQuickLookable
- Rewrote dump() function to not use _reflect()
- CGRect, CGPoint, CGSize now conform to CustomDebugStringConvertible
- Rewrote unit tests for compatibility with new API
...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 :-)
As noted in FIXME(performance), calling `.removeAll(keepCapacity: true)` on a
containter of type Dictionay or Set causes a copy of its storage being made.
Only then, it would proceed to delete each element.
This patch makes these hashed collections skip the wasteful copying step.
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.
as noted in the comment, the native storage version of Set and Dictionary can
be considered equal if their Owner object have the same address. This should
speed up == by quite a bit in those cases.
use === for equality of HashedCollection owner
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
Revert "For unsafeReferenceCast rely on static verifier checks."
This reverts commit r32796.
This reverts commit r32795.
They very likely broke a buildbot.
Swift SVN r32813
unsafeBitCast should only be used when we actually need to lie to the type system (as opposed to just having an unchecked downcast).
Theses are the places where unsafeReferenceCast makes sense:
(In general it makes sense whenever the source & dest are class or class existential types)
- ArrayBuffer.getElement.
The deferred downcast case cannot be benchmarked. It is never on the critical path.
The ObjC array case cannot conceivably matter either, however, it is touched by
DollarChain, JSONHelperDeserialize, and StrSplitter.
These benchmarks do not regress at -O.
- arrayForceCast
No regressions at -O based on microbenchmarks.
None of these remaining cases affect PerfTestSuite at -O:
- General ObjC bridging
- Set/Dictionary bridging
- String bridging
- AutoreleasingUnsafeMutablePointer
These are confirmed speedups but I did not investigate the cause:
|.Chars...................|.32.1%.|
|.Sim2DArray..............|.15.4%.|
|.Calculator..............|.13.0%.|
|.RecursiveOwnedParameter.|..7.9%.|
Swift SVN r32796
Instead of Optional entries use a third bitmap array to mark whether an entry is
valid. This representation saves space (because individual entries don't have a
alignment padding slack) and simplifies ARC's job leading to better performance.
Speedup measured (before/after) at -O:
DictionaryHashableClass`````````3.1
DollarFilter````````````````````1.3
DollarMap```````````````````````1.3
DollarReduce````````````````````1.4
JSONHelperDeserialize```````````1.4
NSDictionaryImplicitConversion``1.4
NSXMLParser`````````````````````1.3
Speedup measured (before/after) at -Onone:
DictOfArraysToArrayOfDicts``````1.3
Dictionary``````````````````````3.5
Dictionary2`````````````````````3.2
Dictionary3`````````````````````3.2
DictionaryHashableClass`````````1.9
DictionaryHashableStruct````````2.4
DictionaryRemove````````````````3.3
DictionarySwap``````````````````2.5
DollarFilter````````````````````1.2
DollarMap```````````````````````1.2
DollarReduce````````````````````1.3
Forest``````````````````````````1.8
Histogram```````````````````````1.6
JSONHelperDeserialize```````````1.6
NSDictionaryImplicitConversion``1.3
Prims```````````````````````````2.9
RGBHistogram````````````````````1.4
rdar://22173734
Swift SVN r32244
Keeping this method in the swift dylib saves a few kilobytes for each
specialization of dictionary. This function is not on the critical
performance path and we don't gain much from pulling it and specializing
it in user code.
Swift SVN r31507
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
