-
Notifications
You must be signed in to change notification settings - Fork 10.5k
draft: Improve map performance through unsafe uninitialized capacity #83297
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
base: main
Are you sure you want to change the base?
draft: Improve map performance through unsafe uninitialized capacity #83297
Conversation
@swift-ci please test |
@swift-ci please benchmark |
There's a bit more going on wrt the old method where the mangled name shows up in SwiftOnoneSupport.swift here:
So I'm afraid I'll have to wrap my had around how to fix the ABI part before tests will pass. |
@glessard has been wrangling with Onone support for similar issues, and should be able to help out once he has a clearer picture of how to move these forward. |
Indeed. I have a PR here dealing with generalizing this Array initializer, and the next step is to solve the ABI issue with SwiftOnoneSupport. |
Ah ok great thanks @glessard I'll adjust my PR once yours is merged! |
e686d28
to
2e6a661
Compare
@swift-ci please test |
@swift-ci Apple Silicon benchmark |
Avoid capturing state that's also available from our parameters Co-authored-by: Guillaume Lessard <[email protected]>
Co-authored-by: Guillaume Lessard <[email protected]>
Thanks for the review @glessard ready for another test run |
@swift-ci please smoke test |
Co-authored-by: Guillaume Lessard <[email protected]>
Oops, fixed! Will clean up the commits a little once we have some results (don't have access to my machine right now sorry) |
@swift-ci please smoke test |
Not sure what happened to the windows build. Shall we try to run the benchmarks? |
@swift-ci please benchmark |
@swift-ci test Windows platform |
stdlib/public/core/Collection.swift
Outdated
for _ in 0..<n { | ||
result.append(try transform(self[i])) | ||
formIndex(after: &i) | ||
return try unsafe Array<T>(unsafeUninitializedCapacity: n) { ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@glessard I assume we'll update this to use an OutputSpan-based init once that's feasible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be preferable indeed.
The benchmarks aren't good news, with much worse regressions than improvements. It would be nice to know more about the example where you saw an improvement: Performance (x86_64): -O
Code size: -O
Performance (x86_64): -Osize
Code size: -Osize
Performance (x86_64): -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
|
@swift-ci Apple Silicon benchmark |
It looks like this change is identifying an optimization that sometimes takes place in map-reduce chains? The only real effect here should be the elimination of uniqueness checking in |
Fairly sure the regression is due to |
Avoid bridging by building a `ContiguousArray`
@swift-ci please benchmark |
Sorry currently travelling until August 2nd. If this new benchmark run is still not conclusive, I will share our test when I'm back |
I analysing performance of a piece of code where a call to map was inside a hot path. Most time was spent inside the append method inside map's implementation.
When replacing the implementation with the changes above we saw a significant performance increase (Will add numbers and a way to reproduce after running ci benchmarks)
These changes ofcourse need some additional work to make sure ABI is maintained which I'd like to pursue once the performance benefits of these changes are confirmed.