-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
DO NOT MERGE: map_split perf test #51643
Conversation
Add Ref/RefMut map_split method As proposed [here](https://internals.rust-lang.org/t/make-refcell-support-slice-splitting/7707). TLDR: Add a `map_split` method that allows multiple `RefMut`s to exist simultaneously so long as they refer to non-overlapping regions of the original `RefCell`. This is useful for things like the slice `split_at_mut` method.
r? @aidanhs (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try |
🔒 Merge conflict |
OK, I resolved the merge conflicts, so bors should be OK with it now. |
@bors try |
DO NOT MERGE: map_split perf test This PR represents the cherry-pick of #51466 and #51630 onto [b81da2](b81da27) (the commit just before #51466). Comparing the performance of this PR to the performance of b81da2 should give us an apples-to-apples comparison of the optimized version of `map_split` against a previous world in which `map_split` doesn't exist, and refcounts can only represent a single writing reference. cc @nnethercote @rkruppe @RalfJung @kennytm
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
☀️ Test successful - status-travis |
It seems that bors merges master into this before running perf? So to actually compare apples with apples we'd have to take care that the two merges happen at the same time? |
I'm not sure what you mean by "two merges happen at the same time"? |
I mean that if this PR gets merged into master and perf runs, and then 2 days later the other PR gets merged into master and perf runs, the difference could also come from stuff that has happened in master in the mean time. Ideally, perf would run on the PR, not on the PR merged into master. Or maybe it does? I just inferred it would not from the fact that merge conflicts were an issue. |
Ping from triage! @Mark-Simulacrum are the perf results ready? |
@kennytm Do you disagree with the concern that others have raised that that perf run isn't an apples-to-apples comparison? |
Honestly I think the goal of the perf check is to show a -4% improvement to offset #51466 (comment), not a strict apple-to-apple comparison. The perf result in #51630 (comment) should be a sufficient signal to say the fix works. |
#51630 has been r+'ed (plus we've got another apple-to-apple comparison at #51630 (comment)), so closing this PR now. |
This PR represents the cherry-pick of #51466 and #51630 onto b81da2 (the commit just before #51466). Comparing the performance of this PR to the performance of b81da2 should give us an apples-to-apples comparison of the optimized version of
map_split
against a previous world in whichmap_split
doesn't exist, and refcounts can only represent a single writing reference.cc @nnethercote @rkruppe @RalfJung @kennytm