replace vec::Drain drop loops with drop_in_place#85157
Conversation
|
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
|
⌛ Trying commit 5cd25a3c8de8ac50571849c91869d27b0aedf1b4 with merge f43378a4f09d5d51bfbc4bca4d5abbd28238f176... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
5cd25a3 to
032fa35
Compare
|
@bors try |
|
⌛ Trying commit 032fa35 with merge 29e55f8f91bd74ab69933dd9166d41317e0146b7... |
|
☀️ Try build successful - checks-actions |
|
Queued 29e55f8f91bd74ab69933dd9166d41317e0146b7 with parent 6fd7a6d, future comparison URL. |
|
Finished benchmarking try commit (29e55f8f91bd74ab69933dd9166d41317e0146b7): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
|
seems kind of mixed. @SkiFire13 do you think it would make sense to test your changes on top of these? |
|
I might give it a try, give me a sec to rebase my pr on top of yours. |
|
triage: |
Still on my radar, just haven't had a chance to review it yet. |
032fa35 to
6851b8d
Compare
|
@the8472 if you want to leave the cleanup of spare capacity to something simpler for the future, that seems OK to me as well I think. |
|
@bors r+ |
|
📌 Commit 2d8a11b has been approved by |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (0b42dea): comparison url. Summary: This change led to large relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
|
Nice, better results than the previous perf run. |
|
Is it possible that this introduced a use-after-free? |
| mem::forget(guard); | ||
| let iter = mem::replace(&mut self.iter, (&mut []).iter()); | ||
| let drop_len = iter.len(); | ||
| let drop_ptr = iter.as_slice().as_ptr(); |
There was a problem hiding this comment.
Specifically, Miri says that in this line as_slice points to dangling memory (in some cases, here triggered by the test_replace_range testcase)
There was a problem hiding this comment.
I'm under the impression that the iter should be valid at all times, but I'll have a closer look at the test-case.
The
Drain::dropimplementation came up in #82185 (comment) as potentially interfering with other optimization work due its widespread use somewhere inprintln!@rustbot label T-libs-impl