Streamline try_start code

[Mark-Simulacrum]

This shifts some branches around and avoids interleaving parallel and
non-parallel versions of the function too much.

[rust-highfive]

r? @petrochenkov

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

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 35c2e168da494b028f3ddee7c7a4b1d8472d8273 with merge 2a30499874245ed414899e7f24a568990a4dfb9c...

[bors]

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

[rust-timer]

Queued 2a30499874245ed414899e7f24a568990a4dfb9c with parent 4de7572, future comparison URL.

[rust-timer]

Finished benchmarking try commit (2a30499874245ed414899e7f24a568990a4dfb9c): 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

[petrochenkov]

r? @cjgillot

[cjgillot]

I like how this reduces the spaghettiness of the current code.
The bootstrap perf effect is small but interesting.
The runtime perf effect is marginally negative: do you have an idea why?

[cjgillot]

@bors r+

[bors]

📌 Commit ba04d692fdb2e1ffdb6aae053c44dd8fb6841cab has been approved by cjgillot

[Mark-Simulacrum]

Pushed a cleanup fix to the code, but no performance fix quite yet.

I think the performance regression is because we're generating some extra code due to needing to re-fill the slot if we're encountering a cycle error; the entry API avoided this because it never inserted into an occupied slot. It's not entirely obvious though if this is the actual cause or not, hard to say.

Looking at a possible fix, in the meantime let me @bors r-

[Mark-Simulacrum]

@bors try @rust-timer queue

Went back to using entry API, but still seems to be a compile-time win, just only ~0.5% instruction count wise. Will update PR description if the perf run comes back with no performance regression.

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 025590ac7ba56a345e466a5c362e27251636cce3 with merge 75f6f6764205c5299fcdc2061a07476875511331...

[Mark-Simulacrum]

@rust-timer build 75f6f6764205c5299fcdc2061a07476875511331

[rust-timer]

Queued 75f6f6764205c5299fcdc2061a07476875511331 with parent 89ebad5, future comparison URL.

[rust-timer]

Finished benchmarking try commit (75f6f6764205c5299fcdc2061a07476875511331): 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

[Mark-Simulacrum]

Looks like it retained the win on compile-time and is a slight bit faster, even.

[Mark-Simulacrum]

r? @cjgillot

[cjgillot]

@bors r+

[bors]

📌 Commit 981135a has been approved by cjgillot

[bors]

⌛ Testing commit 981135a with merge 777bb2f...

[bors]

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 777bb2f to master...