Improve Enum function performance (TryParse, ToString, Parse, etc...) #79762
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
Could you please share sources for your benchmarks? Note that .NET 8 has some enum performance improvements already (e.g. #78580). |
|
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsDescriptionAlthough the Enum code performance has been greatly improved throughout .NET Core and a lot of the worst offenders (HasFlag) have been improved there are still clearly performance gains to be had. In our MSInternal service we still use a home brewed EnumHelper class for our frequent use of TryParse and ToString. Although performance on the default implementations has improved in recent .NET versions it's still significantly less performant as our home brewed solution and even slower compared to some widely available libraries I've also tested FastEnum and Enums.NET. The downside of including such libraries are the same as always, increasing complexity of dependency graphs and the question of ownership and maintainability. ConfigurationProduction scenario: Benchmarking scenario: Regression?No DataThese charts contain four different paths, the default .NET functions, our homebrewed solution that involves a little caching on top of the default implementation, and then the paths of two libraries FastEnum and Enums.NET. The Parse methods include two tests for each, one where a string is provided and one where only a ReadOnlySpan is provided so implementations that can work well with spans are preferred. ToString net6.0
ToString net7.0
Parse net6.0
Parse net7.0
AnalysisThe problem almost certainly in not enough caching. All of these different solutions revolve around using reflection at runtime to look up the values of these values. The faster solutions generally use more caching to speed up performance. I'd suggest the .NET implementation either take a more aggressive approach to caching and or potentially look into using source generators to negate the startup cost associated with the caching altogether.
|
dakersnar
added
the
needs-author-action
|
This issue has been marked |
|
This issue has been automatically marked |
|
This issue will now be closed since it had been marked |
ghost
locked as resolved and limited conversation to collaborators
tannergooding
removed
the
needs-author-action
Description
Although the Enum code performance has been greatly improved throughout .NET Core and a lot of the worst offenders (HasFlag) have been improved there are still clearly performance gains to be had. In our MSInternal service we still use a home brewed EnumHelper class for our frequent use of TryParse and ToString. Although performance on the default implementations has improved in recent .NET versions it's still significantly less performant as our home brewed solution and even slower compared to some widely available libraries I've also tested FastEnum and Enums.NET. The downside of including such libraries are the same as always, increasing complexity of dependency graphs and the question of ownership and maintainability.
Configuration
Production scenario:
net6.0
Windows Server Evergreen
x64
Various
Benchmarking scenario:
net6.0 and net7.0 as labeled
Windows 11 22H2
x64
i7 8700k
Regression?
No
Data
These charts contain four different paths, the default .NET functions, our homebrewed solution that involves a little caching on top of the default implementation, and then the paths of two libraries FastEnum and Enums.NET. The Parse methods include two tests for each, one where a string is provided and one where only a ReadOnlySpan is provided so implementations that can work well with spans are preferred.
ToString net6.0
ToString net7.0
Parse net6.0
Parse net7.0
Analysis
The problem almost certainly in not enough caching. All of these different solutions revolve around using reflection at runtime to look up the values of these values. The faster solutions generally use more caching to speed up performance. I'd suggest the .NET implementation either take a more aggressive approach to caching and or potentially look into using source generators to negate the startup cost associated with the caching altogether.
The text was updated successfully, but these errors were encountered: