Parsing string to enum with digit as first char takes a very long time

[FWest98]

Note: This has to do with mscorlib. https://github.com/Microsoft/referencesource sent me here, but this doesn't look like the place where this is handled. Am I right?

When parsing strings to enums with TryParse, in some cases this takes way longer than in all the other cases. After a bit of research I found that all the strings with a digit as first char are slower. This is due to the attempt to parse the string to the underlying type (https://github.com/Microsoft/referencesource/blob/master/mscorlib/system/enum.cs#L441) with a Convert.ChangeType, which can throw an exception, because further down the line it uses (for example) Int32.Parse instead of TryParse (https://github.com/Microsoft/referencesource/blob/master/mscorlib/system/convert.cs#L1121).

The time it takes to create the Exception is significant. In my project I ended up writing a new Enum parser to circumvent this issue.
"Something": 240.49 ns per parse
"1Somethin": 37178.57 ns per parse
"123456789": 485.63 ns per parse

As users expect Convert.ToXxx() to throw an exception when it fails, changing this is a bad idea I think. Possible solutions I can think of:

• Extend the Convert class with Try-methods that don't throw exceptions, and use those while trying to parse an enum (much work)
• Instead of checking whether the first character is a digit (https://github.com/Microsoft/referencesource/blob/master/mscorlib/system/enum.cs#L434), change that line to a TryParse of the whole string (the easier way)

[Alexx999]

@KrzysztofCwalina @stephentoub Have you started working on this yet? If not - I'd like to look into it.

I believe this can be speed up done using some greedy assumption that any signed value must fit into long, and any unsigned - into ulong to speed up "is integer" check.
Or maybe just walk through the string with for-loop and check if every symbol is digit - that'll make it too (probably even better).

PS: maybe this issue should be moved to coreclr?

[FWest98]

Ah great. I wonder why I didn't see that repo before. I will file an issue over there as well!

I think using TryParse instead of normal Parse is better, but then you have to circumvent the Convert class and find another way to convert to the base type. I think your solution is a better compromise then.

[KrzysztofCwalina]

I have not started to work on this. I think it would be great if you could submit a proposal for API change and then implement the addition. You can read on submitting API change proposals on https://github.com/dotnet/corefx/wiki/API-Review-Process

[Alexx999]

@KrzysztofCwalina I hope that there is no real need to make API behavior change here - hence no need to make API change proposal. Just make existing one faster.
At least if we're not going to implement non-throwing version of Convert methods (while this has some sense in general it will be probably overkill for this case)

[FWest98]

@Alexx999 The implementation of non-throwing Converts would be another case, but may be nice as well. But indeed, I think changing the single if-statement to a for-loop or something else doesn't need an API change.....

[KrzysztofCwalina]

@Alexx999, above you said you would like to start working on this issue. How is it going? I just noticed this issue is assigned to me and so I would be interested in moving it forward.