Use the Regex source generator in the AlphaRouteConstraint.

[eerhardt]

The Regex source generator is faster because it doesn't need to interpret the regex. It does add slightly more code to the compiled app, but the tradeoff seems worth it.

I switched the pattern from a-z with IgnoreCase to A-Za-z because the source generator generates better code with that pattern.

The results of the changed Benchmark shows a 9-10% faster when using an alpha constraint:

Before

Method	Mean	Error	StdDev	Op/s	Ratio	Gen 0	Gen 1	Gen 2	Allocated
TreeRouter	1.362 us	0.0107 us	0.0100 us	734,023.0	1.00	0.0134	-	-	1 KB
EndpointRouting	1.763 us	0.0107 us	0.0100 us	567,280.4	1.29	0.0134	-	-	1 KB

After

Method	Mean	Error	StdDev	Op/s	Ratio	Gen 0	Gen 1	Gen 2	Allocated
TreeRouter	1.230 us	0.0087 us	0.0082 us	813,331.4	1.00	0.0134	-	-	1 KB
EndpointRouting	1.615 us	0.0068 us	0.0063 us	619,255.2	1.31	0.0153	-	-	1 KB

Size

Publishing a Linux NativeAOT app shows about a 4 KB increase in code size with this change:

Before: 27.1 MB (28,483,016 bytes)
After : 27.1 MB (28,487,464 bytes)

[javiercn]

This looks great!

[gfoidl]

Note for further optimization potential:
Instead of relying on Regex for this, the Match could be expressed in terms of dotnet/runtime#76106 or dotnet/runtime#68328, thus avoiding Regex's overhead (and allocations).

[danmoseley]

I switched the pattern from a-z with IgnoreCase to A-Za-z because the source generator generates better code with that pattern.

Is there a regex issue for that? @stephentoub
(This is invariant culture)

[stephentoub]

I switched the pattern from a-z with IgnoreCase to A-Za-z because the source generator generates better code with that pattern.

Is there a regex issue for that? @stephentoub (This is invariant culture)

There's no "issue"... it's by design: [a-z] (IgnoreCase) and [A-Za-z] are functionally different (ever so slightly)... the former recognizes the Kelvin sign as being case-equivalent to k/K. So the difference in the code gen is that when using [A-Za-z], we generate:

char.IsAsciiLetter(slice[iteration])

whereas with [a-z] under IgnoreCase, we generate:

((ch = slice[iteration]) < 128 ? ("\0\0\0\0\ufffe\u07ff\ufffe\u07ff"[ch >> 4] & (1 << (ch & 0xF))) != 0 : RegexRunner.CharInClass((char)ch, "\0\u0006\0A[a{KÅ"))

With more work and analysis we could optimize the latter to instead be:

char.IsAsciiLetter(ch = slice[iteration]) || ch == '\u212A'

or something like that, but it still has the additional check.

(I think it's fine to use [A-Za-z] here, though. Technically it's a breaking change, but I struggle to imagine anyone relying on Kelvin being equal to k or K in routes :)

[eerhardt]

Instead of relying on Regex for this,

The public inheritance here is a problem.

AlphaRouteConstraint is a public class that inherits from RegexRouteConstraint.

1. RegexRouteConstraint's constructors take a Regex or a string. I would need to make a new internal ctor just for this class.
2. RegexRouteConstraint's implementation of IRouteConstraint.Match is not virtual. In order to make this work without any breaking changes, I would need to explicitly implement IRouteConstraint.Match, and you would get different behavior depending on how you cast the object.

[eerhardt]

the former recognizes the Kelvin sign as being case-equivalent to k/K.

Sounds like that was an existing bug, given its documentation: https://learn.microsoft.com/en-us/dotnet/api/system.web.mvc.routing.constraints.alpharouteconstraint

Constrains a route parameter to contain only lowercase or uppercase letters A through Z in the English alphabet.

for what it is worth:

https://xkcd.com/
https://xKcd.com/
https://xKcd.com/

All take me to the same place.

[danmoseley]

With more work and analysis we could optimize the latter to instead be:
char.IsAsciiLetter(ch = slice[iteration]) || ch == '\u212A'

On the face of it that seems like that would be a worthwhile improvement for a fairly common looking pattern?

[stephentoub]

dotnet/runtime#77604

[eerhardt]

I believe all feedback has been addressed. This should be ready for review.