Don't delegate to default implementations of ExactSizeIterator

[yotamofek]

The default ExactSizeIterator calls self.size_hint() and then performs an assertion that the size hint's lower and higher bounds are equal, which is wasteful.

I'm sure the compiler/LLVM can elide that assertion in most cases (e.g. when the size_hint impl returns something like (n, Some(n)), but it still might affect inlining decisions, and maybe even cause LLVM to have to work harder.

There are a lot of changes here, some of which are not as clear-cut as others, so first I wanna see if this has any perf impact.

[yotamofek]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: ccdc19f (ccdc19f7ab8fe127cb8759c4ac5efb5ff7e80b2e, parent: cf8a95590a1b768b7711f2631d5b5e3ead464de7)

[rust-timer]

Finished benchmarking commit (ccdc19f): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary -3.3%, secondary -2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.3%	[-3.9%, -2.6%]	2
Improvements ✅ (secondary)	-2.4%	[-2.4%, -2.4%]	1
All ❌✅ (primary)	-3.3%	[-3.9%, -2.6%]	2

Cycles

Results (primary -1.2%, secondary -0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.6%	[2.6%, 2.6%]	1
Regressions ❌ (secondary)	3.0%	[2.6%, 3.4%]	2
Improvements ✅ (primary)	-2.5%	[-2.9%, -2.3%]	3
Improvements ✅ (secondary)	-3.5%	[-4.3%, -2.2%]	3
All ❌✅ (primary)	-1.2%	[-2.9%, 2.6%]	4

Binary size

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

Bootstrap: 470.335s -> 470.278s (-0.01%)
Artifact size: 386.93 MiB -> 386.95 MiB (0.01%)

[rustbot]

r? @scottmcm

rustbot has assigned @scottmcm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[yotamofek]

Putting this up for review.

Perf is mostly neutral (secondary benchmark that regresses looks bimodal?), so not sure at all whether it's worth the effort and complexity that this adds.

OTOH, maybe code outside of rustc uses ExactSizeIterator as an optimization more often than rustc, due to it being stable, unlike TrustedLen. So maybe there's code out there that will benefit from this.
I dunno..

I don't mind just abandoning this, or maybe whittling it down to only the very straight forward changes.