BTree: avoid most unsafe code in iterators

[ssomers]

Let's see what performance we get by removing most of the _unchecked distinction in the internal iterator API, which is supposed to speed up iterators that track the remaining length while iterating and therefore never hit the "end" of a tree. We still let these iterators track remaining length because that's also needed to offer accurate size_hints to BTree clients.

The essential difference are simple null checks: we pass around Option<Handle<…>> instead of Handle<…> (where the handle has a NonNull niche).

Alloc's benchmarks are indecisive: depending on how much of these changes are considered, some benchmarks win and some loose.

r? @Mark-Simulacrum

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit f074e79158e6b8558a80dbfeae8da79d0a62ae82 with merge 402059575e35429b87602381a02705d86b3fd88b...

[bors]

☀️ Try build successful - checks-actions
Build commit: 402059575e35429b87602381a02705d86b3fd88b (402059575e35429b87602381a02705d86b3fd88b)

[rust-timer]

Queued 402059575e35429b87602381a02705d86b3fd88b with parent dd94145, future comparison URL.

[rust-timer]

Finished benchmarking try commit (402059575e35429b87602381a02705d86b3fd88b): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[ssomers]

Performance seem to suffer a tiny bit, much less than the influence of #[inline].

Last commit is a plain rebase, but restoring the #[inline] on the public next_checked and next_back_checked functions that #85980 added. I removed those #[inline] in the original commit because the underlying unsafe functions got literally inlined in them and did not have #[inline]. Now I suspect the #[inline] matters mostly on pub functions, and the above measurement is mostly affected by the disappearance of those #[inline] just like the initial commit of #85980 was.

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 40079f6f60f1b522b70e340353b58caafeab8f63 with merge 4ef624de06d9a49d294a504b745673d694b1885a...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4ef624de06d9a49d294a504b745673d694b1885a (4ef624de06d9a49d294a504b745673d694b1885a)

[rust-timer]

Queued 4ef624de06d9a49d294a504b745673d694b1885a with parent 9d93819, future comparison URL.

[rust-timer]

Finished benchmarking try commit (4ef624de06d9a49d294a504b745673d694b1885a): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[ssomers]

Not sure this is worth the trouble but here it is rebased.

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit dc3c8df with merge f0274b9b17d524ee8d22d030f9ec8a9f95d70f29...

[bors]

☀️ Try build successful - checks-actions
Build commit: f0274b9b17d524ee8d22d030f9ec8a9f95d70f29 (f0274b9b17d524ee8d22d030f9ec8a9f95d70f29)

[rust-timer]

Queued f0274b9b17d524ee8d22d030f9ec8a9f95d70f29 with parent 432e145, future comparison URL.

[rust-timer]

Finished benchmarking try commit (f0274b9b17d524ee8d22d030f9ec8a9f95d70f29): comparison url.

Summary: This change led to significant regressions 😿 in compiler performance.

• Moderate regression in instruction counts (up to 1.0% on incr-patched: println builds of cargo-opt)

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

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler 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 fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

[ssomers]

Bootstrap timing went up from 0.1% over 0.2% to 0.3% as other differences were ironed out. Is it trying to say something?