Improve performance of Enum.Parse/TryParse

[stephentoub]

The allocation profile of Enum.Parse today is fairly poor. While the design of the method returning an Enum requires at least one allocation for the boxed result (the generic TryParse could be overhauled to avoid this, but still has it), additional allocations shouldn't be necessary in the common cases. However, for some reason the current code is boxing a 0 on every call. It's also using string.Trim() to remove whitespace (once for the overall string and then once for each substring), and using String.Split to parse multiple values, which ends up allocating a string[] and an int[] even if there's only one value.

This commit removes all allocations from Enum.Parse other than the boxing of the Enum result and some allocations on the code path where Enum.Parse is handed a string containing a number, in which case additional allocations are involved in using the Convert.ChangeType call.

With an enum like:

[Flags]
enum Colors
{
    Red = 0x1,
    Orange = 0x2,
    Yellow = 0x4,
    Green = 0x8,
    Blue = 0x10
}

using Enum.Parse(typeof(Color), "Red") repeatedly now results in 5x fewer gen0 GCs and is ~15% faster. Using Enum.Parse(typeof(Color), "Red, Orange, Yellow, Green, Blue") repeatedly now results in 23x fewer gen0 GCs is is similarly ~15% faster.

cc: @jkotas, @ellismg

[jkotas]

I think while (valueIndex <= value.Length) here would make it easier to understand.

Also, why is not the condition of the loop just valueIndex < value.Length? I guess it is handling some empty string corner case - comment on it would be nice.

[stephentoub]

The equals is to handle the case where the string ends with a comma.

I can change it to a while instead of a for.

[jkotas]

LGTM. Very nice improvement.

[stephentoub]

Thanks, @jkotas. Feedback addressed.

[jkotas]

👍