This whole project has become much more complex than initially expected. The most difficult part was coming up with a reliable and overall-applicable testing framework to accurately measure the performance variations. Nevertheless, the results of this extra-effort are certainly worthy: not only a more efficient ParseNumber version, but also lots of relevant insights about performance improvement (comparison and testing) under very demanding conditions.

I did come up with the first good enough version of the new code relatively quickly, but didn't make the final decision about certain parts until after all the tests were completed. In fact, I found various issues whose almost irrelevant effect on performance was kind of surprising to me; all of them are mentioned in the previous section.

The last version of the modified code (i.e., the one in my pull request to CoreCLR) includes various changes in ParseNumber and in the second MatchChars overload with respect to the original version. The table below these lines includes a reference to each of them, together with a % estimation of its contribution to the overall improvement (as defined in the last section of the Tests part).

Modification	Contribution (%)
altdecSep & altgroupSep removal	40
signflag removal	30
Redefinition of IsWhite(ch)-headed conditions	12
Redefinition of MatchChars(char* p, char* str)	11
bigNumberHex removal	7

All the aforementioned modifications refer to variable and method names present in the original version of the code. The justification for all these improvements should be more or less evident, except perhaps the bigNumberHex removal. Note that this modification implies to remove a Boolean variable (bigNumberHex) by replacing it with the less-efficient chunk of code (bigNumber && ((options & NumberStyles.AllowHexSpecifier) != 0)). Such a trade-off is positive because of happening in a part which is rarely used (i.e., all the benefits of removing one variable, but almost none of the slower-code drawbacks). Note that bigNumberHex is only used with hexadecimal inputs (i.e., a not-too-likely scenario); and even in this situation, exclusively with the non-numerical characters (note that a hexadecimal value might consist only in numbers). Thus, the affected condition is verified most of the times through the first short-circuited term by ignoring the new slower code.