Avoid allocating Regex when using static methods

[stephentoub]

Regex supports a cache that's meant to be used for the static methods, e.g. the static Regex.IsMatch. However, currently that cache isn't caching the actual Regex class, but rather a sub object that stores some of the state from the Regex and then is used to rehydrate a new Regex instance. This means we allocate a new Regex object when these static methods are used, even if the data is found in the cache. This means an operation like the static Regex.IsMatch is never allocation-free. There's also weirdness around this caching, in that when a new Regex instance is constructed, it checks the cache (paying the relevant lookup costs) even though it doesn't add back to the cache, so the only way it would ever find something in the cache is if the same set of inputs (e.g. pattern, options, timeout, etc.) are used with both the Regex ctor and with the static methods, where the static methods would populate the cache that's then consulted by the ctor. This adds unnecessary expense on the common path for a very uncommon situation; it also complicates the code non-trivially.

This commit changes things to cleanly separate the cache from Regex, and to actually cache the Regex instance itself.

Running the "Regex*Static" perf tests:

Method	Toolchain	Options	Mean	Error	Ratio	Allocated
EmailStatic	new	None	487.9 ns	5.22 ns	0.97	-
EmailStatic	old	None	500.9 ns	3.57 ns	1.00	104 B
DateStatic	new	None	272.1 ns	2.02 ns	0.88	-
DateStatic	old	None	309.9 ns	0.20 ns	1.00	104 B
IPStatic	new	None	2,233.4 ns	377.74 ns	0.94	-
IPStatic	old	None	2,384.4 ns	330.49 ns	1.00	104 B
UriStatic	new	None	307.6 ns	0.49 ns	0.89	-
UriStatic	old	None	347.3 ns	6.86 ns	1.00	104 B
EmailStatic	new	Compiled	191.9 ns	0.80 ns	0.92	-
EmailStatic	old	Compiled	209.0 ns	1.49 ns	1.00	104 B
DateStatic	new	Compiled	134.3 ns	0.79 ns	0.83	-
DateStatic	old	Compiled	161.1 ns	0.97 ns	1.00	104 B
IPStatic	new	Compiled	410.5 ns	2.21 ns	0.92	-
IPStatic	old	Compiled	445.7 ns	4.37 ns	1.00	104 B
UriStatic	new	Compiled	129.4 ns	0.52 ns	0.83	-
UriStatic	old	Compiled	156.7 ns	0.37 ns	1.00	104 B

cc: @eerhardt, @danmosemsft, @ViktorHofer

[eerhardt]

This looks really good. I just had a few comments on places that confused me while reading the code.

[danmoseley]

@stephentoub just curious, did you also run the other 2 regex perf classes in the perf repo (Perf_Regex and RegexRedux). I am curious how these look with all your recent changes.

[stephentoub]

just curious, did you also run the other 2 regex perf classes in the perf repo (Perf_Regex and RegexRedux). I am curious how these look with all your recent changes.

I have. I'll post numbers in my next PR. Thanks.

[AndyAyersMS]

The benchmarks games "best" C# entry for regex-redux now invokes PCRE. Would be interesting to see how close/far we are from that with our regex implementation and the recent improvements...

[danmoseley]

The benchmarks games "best" C# entry for regex-redux now invokes PCRE. Would be interesting to see how close/far we are from that with our regex implementation and the recent improvements...

It would (we even have a Q6600 we could boot up to measure officially) but as I understand it, that entry avoids the widening to a .NET string that we're still inevitably doing. (Unless we have something like https://github.com/dotnet/corefx/issues/24145 or an equivalent)

[stephentoub]

Failures are due to https://github.com/dotnet/core-eng/issues/8456

[danmoseley]

HashCode.Combine ?

Although in this case, perf is far more important than entropy. Plus, the problem with ^ that it coalesces nulls isn't an issue these won't be null.