Optimize Option::clone to Copy when possible#76551
Closed
ridiculousfish wants to merge 2 commits intorust-lang:masterfrom
ridiculousfish:fix-option-clone
Closed
Optimize Option::clone to Copy when possible#76551ridiculousfish wants to merge 2 commits intorust-lang:masterfrom ridiculousfish:fix-option-clone
ridiculousfish wants to merge 2 commits intorust-lang:masterfrom
ridiculousfish:fix-option-clone
Conversation
Prior to this change, cloning an Option value would branch on whether the Option was Some, even if it would be cheaper to just memcpy the bits. Default the current implementation, and then specialize it for Copy types, to avoid the branch.
Range<T> is not Copy even if T is Copy, which pessimizes the implementation of Option<Range>::clone. Specialize Option::clone for Range so that it can be more efficient. The specialization uses ptr::read to emulate Copy.
Contributor
|
r? @shepmaster (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
Contributor
Author
|
Bad commits, will redo |
shepmaster
reviewed
Sep 10, 2020
| impl<T: Clone> Clone for Option<T> { | ||
| #[inline] | ||
| fn clone(&self) -> Self { | ||
| default fn clone(&self) -> Self { |
Member
There was a problem hiding this comment.
Make sure you check how specialization is used for iterators. As I understand it, it's always behind a helper trait so that specialization doesn't leak out into the public API (like I think this would).
Member
|
It will be good to show benchmarks comparing the before/after performance to help justify the change. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a pair of commits that attempt to improve the codegen of
Option::clone.
The first commit "specializes"
Option<T: Copy>::cloneto a memcpy. Forexample, as of this PR, cloning an
Option<[u8; 8]>)branches on theOption's discriminant link. Copying
the bytes without a branch is more efficient.
The second commit adds the same optimization but specialized for Range.
Range<T: Copy> is famously not Copy (see #27186 and related); I do not
propose to necro that discussion but I would like to see a more efficient
clone(). Because Range is not Copy, this version uses unsafe
ptr::readtoachieve the same effect.
Note: the first commit has a user-visible behavior change in that
Option::clone() will no longer invoke T::clone() if T is Copy. This was
considered as OK in RFC 1521
but it might be worth calling out in release notes.