[Perf] Linux/x64: System.Text.RegularExpressions.Tests.Perf_Regex_Common Regressions on 7/28/2025 3:57:57 AM +00:00

[performanceautofiler]

Run Information

Name	Value
Architecture	x64
OS	ubuntu 22.04
Queue	TigerUbuntu
Baseline	c74a167b25d61a79547da23d2936883c41fd9061
Compare	c87888ac273f859e46370aa8fbde25330fb7a3f2
Diff	Diff
Configs	CompilationMode:tiered, RunKind:micro

Regressions in System.Text.RegularExpressions.Tests.Perf_Regex_Common

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
Uri_IsMatch - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	58.53 ns	65.46 ns	1.12	0.06	False
Uri_IsMatch - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	58.80 ns	65.66 ns	1.12	0.08	False

Test Report

Repro

General Docs link: https://github.com/dotnet/performance/blob/main/docs/benchmarking-workflow-dotnet-runtime.md

git clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f net8.0 --filter 'System.Text.RegularExpressions.Tests.Perf_Regex_Common*'

Details

System.Text.RegularExpressions.Tests.Perf_Regex_Common.Uri_IsMatch(Options: IgnoreCase, Compiled)

ETL Files

Histogram

JIT Disasms

System.Text.RegularExpressions.Tests.Perf_Regex_Common.Uri_IsMatch(Options: Compiled)

ETL Files

Histogram

JIT Disasms

Docs

Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository

[LoopedBard3]

Due to one or more commits from range: 655836e...dc6ac3a. Is there a specific one that you suspect is most likely and is this maybe an acceptable regression regardless, @stephentoub?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-regularexpressions
See info in area-owners.md if you want to be subscribed.

[stephentoub]

Due to one or more commits from range: 655836e...dc6ac3a. Is there a specific one that you suspect is most likely and is this maybe an acceptable regression regardless, @stephentoub?

The only difference that reads on that perf test is #118106. The regex in question contains:

[^\s]*

and that PR causes this set to be properly recognized as \S*, which means the regex engine recognizes it as anything other than whitespace rather than an arbitrary set it doesn't special-case. So, instead of generating code like this:

// Match a character in the set [^\s] atomically any number of times.
{
    int iteration3 = 1;
    while ((uint)iteration3 < (uint)slice.Length && ((ch = slice[iteration3]) < 128 ? ("쇿\uffff\ufffe\uffff\uffff\uffff\uffff\uffff"[ch >> 4] & (1 << (ch & 0xF))) != 0 : RegexRunner.CharInClass((char)ch, "\u0001\0\u0001d")))
    {
        iteration3++;
    }
                            
    slice = slice.Slice(iteration3);
    pos += iteration3;
}

it now generates code like this:

// Match any character other than a whitespace character atomically any number of times.
{
    int iteration3 = 1;
    while ((uint)iteration3 < (uint)slice.Length && !char.IsWhiteSpace(slice[iteration3]))
    {
        iteration3++;
    }
                            
    slice = slice.Slice(iteration3);
    pos += iteration3;
}

But, even if that new version were somehow worse, the kicker is that it's not even exercised as part of this perf test. That loop is part of parsing a URI fragment, which the input url ("http://example.org") used in the perf test doesn't have; there's no #, so it never even gets to that loop.

I also can't repro a regression locally. And in the perf lab, the number seems to be jumping around; the most recent measurement has it faster than it was before, but it looks to be bimodal. And even then it's a few nanoseconds.

I expect any difference here is either then just normal variation or some other aspect of codegen (alignment, JCC erratum, etc.) rearing its head.