[DO NOT MERGE] Experiment: disable the niche optimization for most enums #77816
Conversation
(Only keep it for every small enum to avoid cases where the size is doubling) Trying to use the niche optimisation more often lead to performence regression It would be interresting to know what would be the performence improvement by not having the niche optimization.
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors try @rust-timer queue I'm curious whether this works ... |
|
Awaiting bors try build completion |
|
⌛ Trying commit a8ea6b7 with merge 7273f5a95a6ff81024f115bd286ea713bce5123b... |
|
Awaiting bors try build completion |
|
⌛ Trying commit a8ea6b7 with merge 4db03f51dda11b446970cad86f1e71b517010e74... |
|
🤦 @rust-lang/infra apparently bors and rust-timer will queue twice if I edit the comment, is there a way to fix that? |
|
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
☀️ Try build successful - checks-actions, checks-azure |
|
Queued 4db03f51dda11b446970cad86f1e71b517010e74 with parent c38f001, future comparison URL. |
jyn514
added
A-layout
|
Finished benchmarking try commit (4db03f51dda11b446970cad86f1e71b517010e74): 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 |
|
The result show a small performance improvement, and also some small regressions. I guess there is two factor at play: the gain because the match branch is easier, and the loss because some enum gets bigger. I'm not quite sure how to interpret the result. But I believe the gain would be what we should expect by optimizing the match code generation for niche enum. I guess the difference is not as big as the regression in #70477 because the niche optimization can be used in relatively few enum currently, while #70477 would enable it with many more enum (i think) I'm closing this PR and the discussion can continue on #75866 |
(Only keep the niche optimization for small enum to avoid cases where the size would be doubling)
PR #70477 and #75866 have shown that trying to optimization more often lead to performance regressions.
It would be interesting to know if there would be performance improvements by using the niche optimization less often.
My hypotheses is that the generated code for
matchwhen using the niche optimization is sub-optimal and should deserve to be optimized. This experiment should show how much speed we could expect to gain by optimizing it.I'm kindly asking for a pref run of this PR.
cc @eddyb @erikdesjardins