Reduce Enum.GetEnumName overheads

[stephentoub]

This also helps Enum.ToString(), Enum.IsDefined, etc. Many enums are composed of sequential values starting at 0 (half of all enums exposed from corelib, for example). Today when looking up a value, we search the array of values, but if an enum is known to have such sequential values, we can instead just index into the array at the appropriate location.

privateDayOfWeek_dow=DayOfWeek.Saturday;[Benchmark]publicstringDOWSaturday()=>Enum.GetName(_dow);

Method	Toolchain	Mean	Error	StdDev	Ratio	Code Size
DOWSaturday	\main\corerun.exe	13.271 ns	0.3248 ns	0.5427 ns	1.00	1,383 B
DOWSaturday	\pr\corerun.exe	7.111 ns	0.2060 ns	0.4065 ns	0.54	808 B

[ghost]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This also helps Enum.ToString(), Enum.IsDefined, etc. Many enums are composed of sequential values starting at 0 (half of all enums exposed from corelib, for example). Today when looking up a value, we search the array of values, but if an enum is known to have such sequential values, we can instead just index into the array at the appropriate location.

privateDayOfWeek_dow=DayOfWeek.Saturday;[Benchmark]publicstringDOWSaturday()=>Enum.GetName(_dow);

Method	Job	Toolchain	Mean	Error	StdDev	Ratio
DOWSaturday	Job-SKXTFP	\main\corerun.exe	12.523 ns	0.1381 ns	0.1224 ns	1.00
DOWSaturday	Job-QEFEOM	\pr\corerun.exe	8.019 ns	0.1229 ns	0.1150 ns	0.64

Author:	stephentoub
Assignees:	-
Labels:	area-System.Runtime, tenet-performance
Milestone:	8.0.0

[jkotas]

If you are looking into squeezing more cycles from Enum formatting and parsing, you can try switching on underlying enum CorElementType as the very first thing (using a cached CorElementType for non-generic methods and intrinsic method for the generic methods), and then dispatch to specialized code for each underlying CorElementType.

The benefits of this approach should be:

• Avoid conversions to / from ulong type
• The array of values will be 2x smaller for the most common int underlying type
• Eliminate generic code duplication for Enum methods since the switch will completely evaporate and the rest of the code will be all shared between different Enum types

This would mimic what the high-performance Enum packages out there use, except they typically do that using generic code stamping of the whole thing. Sharing the code per CorElementType should solve that problem.

[drieseng]

@stephentoub Would it possible to also support this for "sequential" enums starting from another value (eg. one), and keep that offset around? I generally prefer to use one for the first value as I don't want a (not nullable) enum field or property to have a (valid) default value if - for some reason - it was not assigned (while it should have been). Perhaps this is not common enough for you to care - and pay the extra cost of keeping an offset around using it where applicable - though, no problem.

[stephentoub]

Perhaps this is not common enough for you to care - and pay the extra cost of keeping an offset around using it where applicable - though, no problem.

Yeah, I'm not sure it's worth it. That's not to say we'd never do it, but it would add cost for everyone, and enums with sequential values starting at 1 are a lot less common than with values starting at 0.

[danmoseley]

Do we have test coverage for both paths?

[drieseng]

@stephentoub, would you consider a PR where the ValuesAreSequentialFromZero bool is replaced with an ulong? (or uint?) whose value would be would be null if the values are not sequential? Not asking you to guarantee that it would be merged of course.

[stephentoub]

That's the same as "keep that offset around" that you asked about earlier :)

[stephentoub]

Do we have test coverage for both paths?

Yes

[drieseng]

@stephentoub, yeah indeed. I just meant to say that it's not necessary to have both the offset and the boolean, I wasn't clear enough. If I find a moment, I'll prepare a PR and we'll see how it affects performance (for both cases).

[stephentoub]

just meant to say that it's not necessary to have both the offset and the boolean

A ulong? is a Nullable<ulong> which is a ulong and a bool 😄

[drieseng]

You can indeed see it that way. As I said, I'll see if I can prepare a PR. If it doesn't meet the bar, that's ok.