Implement more methods for vec_deque::IntoIter

[Sp00ph]

This implements a couple Iterator methods on vec_deque::IntoIter ((try_)fold, (try_)rfold advance_(back_)by, next_chunk, count and last) to allow these to be more efficient than their default implementations, also allowing many other Iterator methods that use these under the hood to take advantage of these manual implementations. vec::IntoIter has similar implementations for many of these methods. This PR does not yet implement TrustedRandomAccess and friends, as I'm not very familiar with the required safety guarantees.

r? @the8472 (since you also took over my last PR)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[the8472]

Have you benchmarked whether they're better than the default impls? If yes please post before/after results.
Vec::IntoIter overrides those methods because it often results in vectorizable code while the default impls don't.
E.g. I suspect next_chunk might benefit less than Vec does because it'll see non-const-length copies even on the Ok branch while Vec only does that for Err.

[Sp00ph]

Have you benchmarked whether they're better than the default impls? If yes please post before/after results. Vec::IntoIter overrides those methods because it often results in vectorizable code while the default impls don't. E.g. I suspect next_chunk might benefit less than Vec does because it'll see non-const-length copies even on the Ok branch while Vec only does that for Err.

I don't think there are currently any benchmarks for vec_deque::IntoIter. I can try to write a few of those later.

[the8472]

I can try to write a few of those later.

Yes, please do. If there aren't significant wins we might as well stick with the defaults.

@rustbot author

[Sp00ph]

@the8472 I added some benchmarks for vec_deque::IntoIter, these are the numbers:

master:

test vec_deque::bench_into_iter                          ... bench:       2,615 ns/iter (+/- 320)
test vec_deque::bench_into_iter_fold                     ... bench:       1,756 ns/iter (+/- 80)
test vec_deque::bench_into_iter_next_chunk               ... bench:       2,458 ns/iter (+/- 2,441)
test vec_deque::bench_into_iter_try_fold                 ... bench:       1,433 ns/iter (+/- 992)

This PR:

test vec_deque::bench_into_iter                          ... bench:       2,560 ns/iter (+/- 161)
test vec_deque::bench_into_iter_fold                     ... bench:       1,751 ns/iter (+/- 45)
test vec_deque::bench_into_iter_next_chunk               ... bench:         546 ns/iter (+/- 17)
test vec_deque::bench_into_iter_try_fold                 ... bench:         640 ns/iter (+/- 30)

Seems like manually implementing fold didn't do that much in this case, but next_chunk and try_fold are significant.

[Sp00ph]

@rustbot ready

[the8472]

Hrrm, I don't think this makes sense. fold shouldn't be slower than try_fold. The issue is that fold takes ownership of the iterator and drops it, so you can't reuse the allocation when benchmarking IntoIter, you can only do that with borrowing iterators. So it must be using the impl Iterator for &mut Iterator indirection which doesn't optimize fold

In that case we just have to bite the bullet and measure the allocation costs together with the iterator performance.

[Sp00ph]

Right, that makes sense. Makes me think, would it maybe make sense to implement the default <&mut Iterator>::fold in terms of Iterator::try_fold? That way it couldn't take advantage of all fold optimizations (try_fold is still unstable), but it would at least work for most stdlib iterators that override try_fold.

[the8472]

There have been several attempts to do that. In fact there currently is an open PR to try that again.

[Sp00ph]

I changed the fold benchmark to use a new deque on every iteration. Now the numbers look like this:

master:

test vec_deque::bench_into_iter_fold                     ... bench:       1,979 ns/iter (+/- 160)

This PR:

test vec_deque::bench_into_iter_fold                     ... bench:         395 ns/iter (+/- 16)

[Sp00ph]

@the8472 friendly reminder :)

[the8472]

@bors r+ rollup=never

[bors]

📌 Commit ccba6c5 has been approved by the8472

It is now in the queue for this repository.

[bors]

⌛ Testing commit ccba6c5 with merge 4507fda...

[bors]

☀️ Test successful - checks-actions
Approved by: the8472
Pushing 4507fda to master...

[bors]

☀️ Test successful - checks-actions
Approved by: the8472
Pushing 4507fda to master...

[rust-timer]

Finished benchmarking commit (4507fda): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	2.5%	[2.5%, 2.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.1%]	1

Cycles

This benchmark run did not return any relevant results for this metric.