String.StartsWith ordinal optimization

[bbowyersmyth]

Optimization for when the first character is different, and for single length compare values.

While it might be unlikely that we get StartsWith(char) and EndsWith(char) overloads we can at least make that faster for the existing StartsWith(string, StringComparison.Ordinal) and single length strings. Bonus is that this also improves any length comparisons where the first char is different.
Single length compare values are common in url processing and text processing (eg quoted strings).

By the time we get to the first character comparison we have already confirmed that value.Length >=1 and that this.Length >= value.Length which means both m_firstChar instances have valid values.

Testing against "abc".StartsWith(value, StringComparison.Ordinal), Release mode, 10M iterations.

Test value	Before	After	Faster
"a" (char match, single length)	173	73	137%
"ab" (match, multi-length)	178	172	4%
"X" (no-match, first char)	183	74	148%
"aX" (no-match, secondary char)	179	172	4%

Unit tests dotnet/corefx#3478. Because this change uses internals it can be confirmed though the System.Runtime.Tests project in Corefx using this gist and checking the testResults.xml file.

[jkotas]

separate if statements regressed multi-character matches by 1%

A few percent is noise for this kind of micro benchmark. It will vary depending on the exact version of the processor, where the code and data happened to be exactly located in memory, ... . Could you please make the code a bit more readable - by having at least one separate if statement?

[jkotas]

LGTM otherwise. I like the performance data you have included in your PR description - it is exactly how performance optimization PR should look like.

[weshaggard]

cc @tarekgh @AlexGhiondea

[bbowyersmyth]

Thanks @jkotas, split it up into a separate if.

[jkotas]

LGTM. @tarekgh @AlexGhiondea could one of you please take a look as well?

[stephentoub]

LGTM

[tarekgh]

LGTM but I expect the case "abc".StartsWith("aX", ....) should be slower after this change as we are adding 2 extra conditions. am I missing something with this case? how we get this case 4% better?

[AlexGhiondea]

👍

[jkotas]

@bbowyersmyth could you please update the "design note" part of the commit description ?

[bbowyersmyth]

@jkotas Removed.
@tarekgh The original commit is not showing up now but that was with the nested conditional operators. I've rerun the tests with the current split if statement and "aX" and "ab" are -0.2%. There might be an extra advantage with conditional operators or as @jkotas suggested, noise. But the results were always pretty consistent.