-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Streamline try_start code #84806
Streamline try_start code #84806
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 35c2e168da494b028f3ddee7c7a4b1d8472d8273 with merge 2a30499874245ed414899e7f24a568990a4dfb9c... |
☀️ Try build successful - checks-actions |
Queued 2a30499874245ed414899e7f24a568990a4dfb9c with parent 4de7572, future comparison URL. |
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 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 |
r? @cjgillot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
35c2e16
to
ba04d69
Compare
@bors r+ |
📌 Commit ba04d692fdb2e1ffdb6aae053c44dd8fb6841cab has been approved by |
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- |
ba04d69
to
025590a
Compare
@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. |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 025590ac7ba56a345e466a5c362e27251636cce3 with merge 75f6f6764205c5299fcdc2061a07476875511331... |
This shifts some branches around and avoids interleaving parallel and non-parallel versions of the function too much.
025590a
to
981135a
Compare
@rust-timer build 75f6f6764205c5299fcdc2061a07476875511331 |
Queued 75f6f6764205c5299fcdc2061a07476875511331 with parent 89ebad5, future comparison URL. |
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 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 |
Looks like it retained the win on compile-time and is a slight bit faster, even. |
r? @cjgillot |
@bors r+ |
📌 Commit 981135a has been approved by |
☀️ Test successful - checks-actions |
This shifts some branches around and avoids interleaving parallel and
non-parallel versions of the function too much.