-
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
Implement specialised clone_from
via #[derive(Clone)]
#27939
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
Looks like I'm also a little worried about this in terms of compile times, |
We've kept this method, maybe we should support it too... |
@alexcrichton I'm not sure how best to benchmark the impact this has on compile times (or whether such results would even be meaningful if I tried to benchmark on my laptop, I seem to get incredibly variable compile times in msys). I agree with @tbu- if this method exists it should be implemented, otherwise it's just giving the illusion that there's a more performant version of clone. I've also found |
Can you generate a test cases along the lines of:
I'm not saying we should not do this, I'm saying that if this doubles compile times then we should think through this before hastily merging. |
I see @alexcrichton mentioning downsides here, but the advantage of doing this isn't clear. The linked issue doesn't describe any concrete wins. Are there theoretical performance improvements? Can they be measured? |
@brson Consider a struct containing a vector, with this derive the |
I agree with @tbu- here - |
Waiting to see how this affects compiletimes per @alexcrichton. |
I ran the two tests @alexcrichton described, code: https://gist.github.com/Diggsey/7268beefb47a2cc9a740 Each test was run five times, and the best result used (all times are in seconds):
So clearly this does have a large negative impact on compile times. However, in real code it's extremely rare to only derive
Unfortunately, rustc overflowed its stack for |
Hm ok, so it looks like this is about a 2x-ish hit (which kinda makes sense) in terms of adding compile time to |
Testing on |
I'm personally feeling that these numbers are significant enough and the benefit is marginal enough that I would prefer to not go forward with this just yet. Perhaps in the future we can enable faster codegen of |
One potential option could be a way of opting in to a derived |
Since this has been stalled a long time, closing per @alexcrichton's reasoning. |
It has been 5 years. Could this be revisited? |
Per the above mention, we needed to manually implement |
This also adds machinery to
derive
so that it can track the mutability of self parameters, which is required so that it can generate the correct match expressions and destructuring.Fixes #13281