New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stdlib][DNM] Remove customization points from Sequence and Collection #19769
Conversation
@swift-ci please smoke benchmark |
@swift-ci please smoke test compiler performance |
@swift-ci please test |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: Swift libraries
How to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview
|
f0d0c2e
to
e02c925
Compare
@swift-ci please smoke benchmark |
@swift-ci please smoke test |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: Swift libraries
How to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the regressions before you merge the PR. Noise: Sometimes the performance results (not code size!) contain false alarms. Unexpected regressions which are marked with '(?)' are probably noise. If you see regressions which you cannot explain you can try to run the benchmarks again. If regressions still show up, please consult with the performance team (@eeckstein). Hardware Overview
|
e02c925
to
f3edb42
Compare
Closing in favor of #19995 |
This removes some unnecessary customization points on standard library protocols:
map
andforEach
onSequence
It is unrealistic that a collection would be able to implement
map
(which takes a transformation closure) to create a mapped array faster than the default implementation.While it is possible that a type's
forEach
implementation might be able to eek out a small performance benefit (for example, to avoid the reference count bump of puttingself
into an iterator), it is generally harmful to encourage this kind of "maybeforEach
could be faster" micro-optimization (for example, see here where error control flow was used in order to break out of the for-each early).first
onCollection
andlast
onBidirectionalCollection
It's important to remove these in order for collections of move-only types to be able to implement these protocols. Returning a single element of the collection inside an optional would otherwise need to consume the entire collection.
While it is conceivable that faster implementations of
first
for particular collections could exist, it's unlikely to be material and experience in benchmarking so far suggests that where they did exist, those implementations were actually slower.