Implement Debug for C-like enums with a concatenated string#155452
Implement Debug for C-like enums with a concatenated string#155452makai410 wants to merge 2 commits intorust-lang:mainfrom
Debug for C-like enums with a concatenated string#155452Conversation
|
Changes to the code generated for builtin derived traits. cc @nnethercote |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Implement `Debug` for C-like enums with a concatenated string
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (5a131e3): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -3.6%, secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.8%, secondary 2.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.4%, secondary 0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 492.421s -> 491.503s (-0.19%) |
|
There was a leftover condition from an earlier PR that I pulled in without a proper review, such that it actually didn't apply the optimization to large enums <_<; I also want to try skipping bounds checks. I suppose it could improve runtime performance, at least on my machine, based on some pretty rough benchmarks with an enum of 10,000 variants. |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Implement `Debug` for C-like enums with a concatenated string
|
I'm happy to review this once it's ready. @rustbot author |
| let variant_names = def | ||
| .variants | ||
| .iter() | ||
| .map(|v| v.disr_expr.is_none().then_some(v.ident.name.as_str())) | ||
| .collect::<Option<ThinVec<_>>>()?; |
There was a problem hiding this comment.
Hmmm, I think I missed a valid case, considering:
enum Uwu {
QwQ = 0,
AwA = 1,
}which has explicit discriminants but is actually dense.
There was a problem hiding this comment.
Also, we can use an offset when some variants have negative discriminants while the overall variants remain dense.
I'll do a follow-up PR to implement these.
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (7348f26): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 0.7%, secondary 0.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 4.4%, secondary 3.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.4%, secondary 1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 493.313s -> 504.472s (2.26%) |
|
This will probably run into #148423. Furthermore, I believe this is likely to cause unsoundness in actual programs, due to the |
|
We still have compile time regression, I suppose that for small enums it might not be worth doing this kind of optimization, I don't think the runtime performance would vary a lot but the compile time has already increased a lot. |
View all comments
Fixes: #114106 #133945
Related to: #88793
Continuation of: #109615 #114190
r? @ghost (I want to see the perf first)