-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add VecDeque::extend from vec::IntoIter and slice::Iter specializations #95904
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
bd9fc4c
to
a86272d
Compare
a86272d
to
9fe4fe1
Compare
9fe4fe1
to
eb492e7
Compare
eb492e7
to
4654996
Compare
r? rust-lang/libs |
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.
I see that you added a benchmark, can you post results? Or show a difference in assembly output? Also, that benchmark only tests the borrowed case, not the owning one.
4654996
to
faf46ce
Compare
I've updated the PR description with the results of the benchmarks
I've added the |
faf46ce
to
c126f7f
Compare
@bors r+ rollup=never |
📌 Commit c126f7f has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (3bfeffd): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
…serve, r=the8472 Remove redundant calls to reserve in impl Write for VecDeque Removes the reserve calls made redundant by rust-lang#95904 (as discussed in rust-lang#95632 (comment))
…serve, r=the8472 Remove redundant calls to reserve in impl Write for VecDeque Removes the reserve calls made redundant by rust-lang#95904 (as discussed in rust-lang#95632 (comment))
…serve, r=the8472 Remove redundant calls to reserve in impl Write for VecDeque Removes the reserve calls made redundant by rust-lang#95904 (as discussed in rust-lang#95632 (comment))
…dlen, r=the8472 Add VecDeque::extend from TrustedLen specialization Continuation of rust-lang#95904 Inspired by how [`VecDeque::copy_slice` works](https://github.com/rust-lang/rust/blob/c08b235a5ce10167632bb0fddcd0c5d67f2d42e3/library/alloc/src/collections/vec_deque/mod.rs#L437-L454). ## Benchmarks Before ``` test vec_deque::bench_extend_chained_bytes ... bench: 1,026 ns/iter (+/- 17) test vec_deque::bench_extend_chained_trustedlen ... bench: 1,024 ns/iter (+/- 40) test vec_deque::bench_extend_trustedlen ... bench: 637 ns/iter (+/- 693) ``` After ``` test vec_deque::bench_extend_chained_bytes ... bench: 828 ns/iter (+/- 24) test vec_deque::bench_extend_chained_trustedlen ... bench: 25 ns/iter (+/- 1) test vec_deque::bench_extend_trustedlen ... bench: 21 ns/iter (+/- 0) ``` ## Why do it this way https://rust.godbolt.org/z/15qY1fMYh The Compiler Explorer example shows how "just" removing the capacity check, like the [`Vec` `TrustedLen` specialization](https://github.com/rust-lang/rust/blob/c08b235a5ce10167632bb0fddcd0c5d67f2d42e3/library/alloc/src/vec/spec_extend.rs#L22-L58) does, wouldn't have been enough for `VecDeque`. `wrap_add` would still have greatly limited what LLVM could do while optimizing. --- r? `@the8472`
Inspired from the
Vec
SpecExtend
implementation, but without the specialization forTrustedLen
which I'll look into in the future.Should help #95632 and KillingSpark/zstd-rs#17
Benchmarks
Before
After