-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Use @_borrowed on a few declarations in the stdlib and overlays #20415
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
Conversation
@swift-ci Please test. |
Build failed |
Build failed |
@swift-ci Please test. |
Build failed |
Build failed |
640c737
to
8bdbac9
Compare
@swift-ci Please test. |
Build failed |
Build failed |
@swift-ci Please benchmark |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibs
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 Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
Most of the stdlib's properties don't need @_borrowed because they're @inlinable, but I did find one place in an overlay where it's probably sensible to make the operation use generalized accessors even if they're resilient.
This is a performance hack: inlining a coroutine can promote heap allocations of the frame to stack allocations, which is valuable out of proportion to the normal weight. There are surely more principled ways of getting this effect, though.
8bdbac9
to
d339eab
Compare
Previous full-test run succeeded. Smoke-testing the minor update. @swift-ci Please smoke test. |
@swift-ci Please benchmark. |
@swift-ci Please smoke test. |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibs
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 Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
@airspeedswift It looks like all the really serious non- |
By the way, I think the perf hit here is that we're calling the read accessor and it's having to allocate space dynamically for its frame. |
@airspeedswift By "ripped out", I mean "having the guts of the implementation so thoroughly replaced that I don't need to worry about a short-term regression". |
Yeah, probably. Which isn't to say you'll still be causing regressions after this but impossible to say what. Let me rebase my PR on this one and see. |
@swift-ci please benchmark |
Re-benchmarking now I’ve merged #20221 |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibs
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 Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
@airspeedswift I think we can remove sequence benchmarks that have |
Also, generally speaking, how much weight should we assign the performance regressions in |
Okay, we agreed to do this. |
@swift-ci Please test. |
No description provided.