-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[stdlib] Remove additional customization points #19995
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] Remove additional customization points #19995
Conversation
@swift-ci please benchmark |
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
|
e4632da
to
2c90d5f
Compare
@swift-ci please test |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
5046158
to
a211184
Compare
@swift-ci please test |
This comment has been minimized.
This comment has been minimized.
a211184
to
3228f7e
Compare
@swift-ci please smoke test |
3228f7e
to
6bc7073
Compare
@swift-ci please smoke test |
6bc7073
to
a122cfb
Compare
@swift-ci please smoke test |
@swift-ci please smoke test linux platform |
1 similar comment
@swift-ci please smoke test linux platform |
@swift-ci please test linux platform |
Build failed |
This removes some unnecessary customization points on standard library protocols:
map
,filter
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.Amended as brought up on the review thread to add more entries:
suffix(from:)
,prefix(upTo:)
andprefix(through:)
These are trivial and really don't need to be customizable.