Use a lookup table in #[derive(Debug)] for fieldless enums

[DaniPopes]

Index into a constant array containing the Debug strings instead of matching directly.

Opening as draft since I don't know the performance implications of this, and would be nice to have a perf run done on this PR.

Closes #114106
Refs #114106 (comment), #106884

[rustbot]

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 4d76b33 with merge fdbb5360b46d689c4d8ca16144ce40a45cb83099...

[bors]

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

[clubby789]

I haven't looked at the implementation yet but my previous attempt at this (#109615) might be of interest

[rust-timer]

Finished benchmarking commit (fdbb5360b46d689c4d8ca16144ce40a45cb83099): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

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 may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try 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-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.3%, 2.6%]	37
Regressions ❌ (secondary)	1.5%	[0.3%, 7.1%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	0.8%	[0.3%, 2.6%]	37

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.9%	[0.5%, 11.7%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-4.0%	[-4.0%, -4.0%]	1
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	2.6%	[-4.0%, 11.7%]	6

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.8%	[0.9%, 2.7%]	7
Regressions ❌ (secondary)	2.0%	[1.3%, 2.9%]	5
Improvements ✅ (primary)	-3.1%	[-5.1%, -1.3%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.5%	[-5.1%, 2.7%]	13

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.0%, 1.9%]	67
Regressions ❌ (secondary)	1.5%	[0.1%, 3.8%]	16
Improvements ✅ (primary)	-0.2%	[-0.4%, -0.1%]	5
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-0.4%, 1.9%]	72

Bootstrap: 649.861s -> 651.137s (0.20%)

[Swatinem]

I have been looking into a similar case recently as noted in #114106 (comment), and part of the problem might be the match statement itself.

For data-less enums with dense/contiguous discriminants, you should be able to just use something like *self as u32 to use the discriminant directly as an index instead of via the match roundtrip.

[davidtwco]

I don't think the perf results warrant landing this as-is, if you have other ideas that you'd like to try then we can re-run the benchmarking with those :)

[DaniPopes]

Closing given negative perf results and I don't really have any idea on how to improve this.