RegexRouteConstraint should use Compiled Regex

Today, when using a regex route constraint, we create a new Regex:

https://github.com/dotnet/aspnetcore/blob/e5238763bddd7100823751c4a4ae0220d78160aa/src/Http/Routing/src/Constraints/RegexRouteConstraint.cs#L40-L43

This should use the RegexOptions.Compiled as well. That way we aren’t interpreting these regular expressions every time the route is inspected.

Our docs even say this should be using Compiled:

The ASP.NET Core framework adds RegexOptions.IgnoreCase | RegexOptions.Compiled | RegexOptions.CultureInvariant to the regular expression constructor. See RegexOptions for a description of these members.

[JamesNK]

@surayya-MS From the discussion in our call, here is an example of configuring the regex route to go back to the old behavior:

public class NonCompiledRegexInlineRouteConstraint : RegexRouteConstraint
{
    public NonCompiledRegexInlineRouteConstraint(string regexPattern)
        : base(new Regex(regexPattern, RegexOptions.CultureInvariant | RegexOptions.IgnoreCase))
    {
    }
}

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRouting(options =>
{
    options.ConstraintMap["regex"] = typeof(NonCompiledRegexInlineRouteConstraint);
});

This is the escape hatch we can recommend to customers if, even after improvements, their app has problems with compiled regexes.

[JamesNK]

Test app with 30,000 regex routes:

using System.Diagnostics;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (HttpContext context, Func<Task> next) =>
{
    Console.WriteLine("Start time");
    Stopwatch stopwatch = Stopwatch.StartNew();

    await next();

    stopwatch.Stop();
    Console.WriteLine(stopwatch.Elapsed.TotalSeconds);
});

app.UseRouting();

Task Plaintext(HttpContext context) => context.Response.WriteAsync("Hello, World!");
for (int i = 0; i < 30_000; i++)
{
    var url = "/plaintext/nested" + i + "/{riskId:regex(^\\d{{7}}|(SI[[PG]]|JPA|DEM)\\d{{4}})}";
    app.MapGet(url, Plaintext);
}

app.MapGet("/", (HttpContext context) =>
{
    return context.Response.WriteAsync("Hello world");
});

Console.WriteLine("Running app");
app.Run();

Time to first request:

• Compiled regex - 1.996s (new)
• Interpreted regex - 0.9421s (old)
• No regex - 0.5757s

App memory usage:

• Compiled regex - 865mb (new)
• Interpreted regex - 385mb (old)
• No regex - 280mb

I think we should:

• Make the constraint store the regex string and make Regex construction lazy until needed.
• Add a cache to DFA builder to share regex instances.

That will bring first request and memory usage down to “no regex” results for most apps. We get our cake and eat it too: improved startup performance and regex per-request performance.

There still might be some edge-case apps out there that perform worst. They have lots of unique regex routes, and they all get visited, and memory usage is a problem. Routing is configurable so we can advise them to configure the regex constraint with an implementation that doesn’t call RegexOptions.Compiled.