When collecting into a Vec, don't reserve extra room if we have a size_hint upper bound

[joshtriplett]

Vec currently forces a minimum number of elements for small vectors
(minimum 4 for most object sizes). This results in wasted capacity for
small vectors, when collecting from an iterator with a known size of 1,
2, or 3.

Vec already effectively does this when collecting from an iterator with
TrustedLen, but doesn't for other iterators.

Try the experiment of doing so for any iterator whose size_hint has a
matching lower and upper bound (iterators that know their exact size).

Found via performance analysis that turned up a missing TrustedLen
resulting in missing this optimization. Credit to Josh Stone for the
idea of doing this for every collect rather than just those on
TrustedLen.

[rustbot]

r? @clarfonthey

rustbot has assigned @clarfonthey.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey

[joshtriplett]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 4d57bc6 (4d57bc6b51991da8e9de83812bc3bf518433feca)
Base parent: ea13733 (ea137335b78829b4514bf1b4c16302f74fab8581)

[rust-timer]

Finished benchmarking commit (4d57bc6): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.3%	[0.1%, 0.4%]	3
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	4
Improvements ✅ (primary)	-0.4%	[-0.8%, -0.2%]	3
Improvements ✅ (secondary)	-0.3%	[-0.4%, -0.1%]	5
All ❌✅ (primary)	-0.1%	[-0.8%, 0.4%]	6

Max RSS (memory usage)

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

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

	mean	range	count
Regressions ❌ (primary)	4.6%	[4.6%, 4.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.7%	[-4.5%, -2.9%]	2
Improvements ✅ (secondary)	-2.6%	[-3.3%, -2.2%]	3
All ❌✅ (primary)	-0.9%	[-4.5%, 4.6%]	3

Cycles

Results (primary -0.2%, secondary 5.0%)

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

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	5.0%	[2.9%, 6.7%]	7
Improvements ✅ (primary)	-2.5%	[-2.5%, -2.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.2%	[-2.5%, 2.1%]	2

Binary size

Results (primary -0.1%, secondary 0.0%)

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

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.3%]	2
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-0.2%	[-0.5%, -0.1%]	5
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.5%, 0.3%]	7

Bootstrap: 496.563s -> 489.622s (-1.40%)
Artifact size: 408.58 MiB -> 408.83 MiB (0.06%)

[ChayimFriedman2]

We can do this on every push, but not sure if this will be beneficial.

[clarfonthey]

I think with this kind of lukewarm perf I would probably only be happy if it simplified the resulting logic, but that's not the case here. Would be happy to be proven wrong with other benchmarks, though; the compiler isn't the only thing using Vec.

[clarfonthey]

(waiting on author could mean waiting on more benchmarks/justification, or code changes, but I don't think I'd be happy merging this as-is given just the existing perf run)

[ChayimFriedman2]

I don't think this will improve performance, at most memory usage.

[joshtriplett]

I don't think this will improve performance, at most memory usage.

Right. My hope here is, roughly, "performance neutral but saves memory".

[clarfonthey]

Okay, I reread and now that feels a bit more clear. Unfortunately, we won't be able to detect this in the compiler since it generally allocates small vectors on the stack.

I do wonder if there'd be a better way to test the impact of this. Memory is historically a very noisy metric.

[joshtriplett]

Okay, I reread and now that feels a bit more clear. Unfortunately, we won't be able to detect this in the compiler since it generally allocates small vectors on the stack.

I do wonder if there'd be a better way to test the impact of this. Memory is historically a very noisy metric.

It's possible to get a better idea locally by running with DHAT or heaptrack.