-
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
VecDeque::resize
should re-use the buffer in the passed-in element
#104435
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
// CHECK-LABEL: @vec_extend_via_iter_repeat_n | ||
pub fn vec_extend_via_iter_repeat_n() -> Vec<u8> { | ||
// CHECK: %[[ADDR:.+]] = tail call dereferenceable_or_null(1234) ptr @__rust_alloc(i64 1234, i64 1) | ||
// CHECK: tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 1 dereferenceable(1234) %[[ADDR]], i8 42, i64 1234, |
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.
This helps show that we can probably use the iterator rather than special custom extend code like
rust/library/alloc/src/vec/mod.rs
Lines 2525 to 2529 in 101e182
if n > 0 { | |
// We can write the last element directly without cloning needlessly | |
ptr::write(ptr, value.last()); | |
local_len.increment_len(1); | |
} |
but Vec
is really important so I don't want to do that in the same PR as this fix.
Hopefully I can do this despite the new API -- with |
e880bef
to
4df448a
Compare
Today it always copies it for *every* appended element, but one of those clones is avoidable.
4df448a
to
d62b903
Compare
Do you want to open an ACP for the new API? I don't mind reviewing the impl, though. |
ACP's already open: rust-lang/libs-team#120 |
Thanks, I'll get to the review tomorrow or so then. |
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.
This is a bit tricky but not very much code and it's pretty well commented, so doesn't seem that bad overall.
r=me on impl, I think it needs the ACP to be seconded to land (although I think the API is a good idea)
@thomcc To be able to decouple the |
After some discussion with other reviewers (for example, @cuviper), I think this is fine. We just need to remember to change the approach if the ACP is rejected, and it probably should be |
@bors r=thomcc rollup |
Unsure about rollup here, shouldn't this be expected to improve perf if the compiler uses VecDeque::resize? (which it might not, but it's hard to say) |
I'll just ask perf, then! @bors r- |
@bors try @rust-timer queue |
@thomcc Given how big the bors queue has been lately, I'd rather do a perf run and rollup than make it run on its own, was my thought. |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (ba6c2e262132dbff0c22d04a0c095a8ff5643767): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@bors r=thomcc rollup |
Two secondary regressions in code that doesn't use |
Rollup of 6 pull requests Successful merges: - rust-lang#103901 (Add tracking issue for `const_arguments_as_str`) - rust-lang#104112 (rustdoc: Add copy to the description of repeat) - rust-lang#104435 (`VecDeque::resize` should re-use the buffer in the passed-in element) - rust-lang#104467 (Fix substraction with overflow in `wrong_number_of_generic_args.rs`) - rust-lang#104608 (Cleanup macro matching recovery) - rust-lang#104626 (Fix doctest errors related to rustc_middle) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
(The rollup had no perf changes, so this was probably neutral.) |
Today it always copies it for every appended element, but one of those clones is avoidable.
This adds
iter::repeat_n
(#104434) as the primitive needed to do this. If this PR is acceptable, I'll also use this inVec
rather than its customExtendElement
type & infrastructure that is harder to share between multiple different containers:rust/library/alloc/src/vec/mod.rs
Lines 2479 to 2492 in 101e182