Improve Guid parsing performance (#20183)
authorStephen Toub <stoub@microsoft.com>
Sat, 29 Sep 2018 23:12:48 +0000 (19:12 -0400)
committerGitHub <noreply@github.com>
Sat, 29 Sep 2018 23:12:48 +0000 (19:12 -0400)
commitc04fee1611a7ad7075bc28d9c4e0546ccdad8b30
tree93ad8d14feb6db0435f48f310e83f188a31b449a
parentecbbcf6edab9c4fb723bd59fba04c8177c977840
Improve Guid parsing performance (#20183)

* Improve Guid parsing performance

Significantly improves the performance of parsing all Guid number styles, primarily by avoiding using the StringToInt core helper that was used previously to parse each of the consistuent components, as well as avoiding some unnecessary searches of the strings in order to determine which format is employed.

I kept strong compatibility with the existing implementation, down to what exceptions are thrown when (even when they’re a bit strange).  However, there are a few cases where the error messages in those exceptions differ from what they previously were, due to ambiguities, and IMO it not being worth making the implementation slower to try to maintain the exact same choice.  For example, the string “{0xdddddddd, 0xdddd 0xdddd,{0xdd,0xdd,0xdd,0xdd,0xdd,0xdd,0xdd,0xdd}}” isn’t parsable, because it’s missing a comma between the second and third components, and with whitespace removed the parser will try to parse “0xdddd0xdddd” and fail to do so.  Previously that would result in an error message “Additional non-parsable characters are at the end of the string”, and now it’ll result in an error message “Guid string should only contain hexadecimal characters.”  Similarly, “(-ddddddd-dddd-dddd-dddd-dddddddddddd)” would previously fail with “Unrecognized Guid format”, and now it’ll also fail with “Guid string should only contain hexadecimal characters.”

* Undo int->uint / short->ushort field changes

* Address PR feedback
src/System.Private.CoreLib/shared/System/Guid.Unix.cs
src/System.Private.CoreLib/shared/System/Guid.cs
src/System.Private.CoreLib/shared/System/Number.Parsing.cs