Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea for reducing enum parsing/formatting overheads #76398

Closed
stephentoub opened this issue Sep 29, 2022 · 2 comments · Fixed by #78580
Closed

Idea for reducing enum parsing/formatting overheads #76398

stephentoub opened this issue Sep 29, 2022 · 2 comments · Fixed by #78580
Assignees
Milestone

Comments

@stephentoub
Copy link
Member

Copying @jkotas' feedback here so we don't lose track of it:
#76162 (review)

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.

@dotnet-issue-labeler
Copy link

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.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Sep 29, 2022
@ghost
Copy link

ghost commented Sep 29, 2022

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

Issue Details

Copying @jkotas' feedback here so we don't lose track of it:
#76162 (review)

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.

Author: stephentoub
Assignees: -
Labels:

area-System.Runtime, untriaged

Milestone: -

@dakersnar dakersnar removed the untriaged New issue has not been triaged by the area owner label Oct 10, 2022
@dakersnar dakersnar added this to the Future milestone Oct 10, 2022
@stephentoub stephentoub self-assigned this Nov 18, 2022
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Nov 18, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Dec 6, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jan 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants