Inline __iterator_get_unchecked for some iterator adapters.

[the8472]

This aligns the inline attributes of existing __iterator_get_unchecked with those of next() on adapters that have both.

It improves the performance of iterators using unchecked access when building in incremental mode (due to the larger CGU count?). It might negatively affect incremental compile times for better runtime results, but considering that the equivalent next() implementations also are #[inline] and usually are more complex this should be ok.

./x.py bench library/core -i --stage 0 --test-args bench_trusted_random_access
OLD: 119,172 ns/iter
NEW: 17,714 ns/iter

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[JohnTitor]

The result on the OP looks neat to me, is it worth running a perf-check?

[m-ou-se]

@bors r+ rollup=never

[bors]

📌 Commit 4f3fafa077a95748cac75f6247eb2ae2fd0cf97c has been approved by m-ou-se

[bors]

⌛ Testing commit 4f3fafa077a95748cac75f6247eb2ae2fd0cf97c with merge 51205365b7eb58544dcf212d26028dfe2e7a587c...

[bors]

💔 Test failed - checks-actions

[the8472]

The bench-executed-as-test overflowed an usize on a 32bit build with overflow checks. It now uses wrapping_add instead to avoid that since the computed results are not relevant to the benchmark, it's just exercising the adapters.

I'll go ahead and assume that that fix is tiny enough that doesn't need a new review.

@bors r=m-ou-se rollup=never

[bors]

📌 Commit a68a5d2 has been approved by m-ou-se

[bors]

⌛ Testing commit a68a5d2 with merge 3d0ac7e...

[bors]

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing 3d0ac7e to master...

[rust-timer]

Finished benchmarking commit (3d0ac7e): comparison url.

Summary:

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	1	2	3	1	4
mean2	0.2%	0.3%	-0.4%	-0.2%	-0.2%
max	0.2%	0.3%	-0.4%	-0.2%	-0.4%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

1. number of relevant changes↩

2. the arithmetic mean of the percent change↩