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.