Vectorize RegexInterpreter opcode loops for Oneloop, Onerep, Notonerep, and MatchString

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra

[danmoseley]

The RegexInterpreter already had a precedent for vectorizing per-character loops: the Notoneloop/Notoneloopatomic opcode used IndexOf for left-to-right matching. This PR extends that pattern to four more opcodes:

1. Oneloop/Oneloopatomic (a+, a*): Use IndexOfAnyExcept(ch) instead of a per-char loop
2. Onerep (a{N}): Use ContainsAnyExcept(ch) instead of a per-char equality loop
3. Notonerep ([^x]{N}): Use Contains(ch) instead of a per-char inequality loop
4. MatchString (literal strings): Use SequenceEqual instead of a per-char comparison loop

All optimizations apply only to left-to-right matching paths. Right-to-left paths (rare) are left unchanged as they can't benefit from forward-scanning vectorization.

These methods (IndexOfAnyExcept, ContainsAnyExcept, Contains, SequenceEqual) are SIMD-accelerated in .NET and process 16–32 chars at a time vs 1-at-a-time in the original loops.

Benchmark Results

Tested on Intel Core i9-14900K, .NET 11.0.0-dev, using BenchmarkDotNet with --corerun comparing before and after builds:

Benchmark	Before	After	Speedup
Oneloop a+ (64 chars)	89 ns	81 ns	~1.1x
Oneloop a+ (256 chars)	180 ns	85 ns	~2.1x
Oneloop a+ (1024 chars)	430 ns	62 ns	~7x
Oneloop a* (256 chars)	144 ns	43 ns	~3.3x
Onerep a{64}	58 ns	28 ns	~2x
Onerep a{256}	245 ns	52 ns	~4.7x
Notonerep [^x]{64}	87 ns	28 ns	~3.1x
Notonerep [^x]{256}	216 ns	30 ns	~7.2x
MatchString (8 chars)	29 ns	26 ns	~1.1x
MatchString (16 chars)	31 ns	28 ns	~1.1x
MatchString (52 chars)	52 ns	29 ns	~1.8x

Zero regressions. Zero allocation changes. Improvements scale with input length as expected from SIMD vectorization.

Benchmark source code

// Licensed to the .NET Foundation under one or more agreements.// The .NET Foundation licenses this file to you under the MIT license.// See the LICENSE file in the project root for more information.usingBenchmarkDotNet.Attributes;usingMicroBenchmarks;namespaceSystem.Text.RegularExpressions.Tests{/// <summary>/// Benchmarks targeting specific interpreter opcode paths:/// Oneloop, Onerep, Notonerep, and literal string matching (MatchString)./// Uses RegexOptions.None to force the interpreter engine./// </summary>[BenchmarkCategory(Categories.Libraries,Categories.Regex)]publicclassPerf_Regex_Interpreter_Vectorize{// --- Inputs ---// Short input (64 chars) to measure per-call overheadprivateconststringShortA="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";// 64 'a's// Medium input (256 chars)privateconststringMediumA=ShortA+ShortA+ShortA+ShortA;// 256 'a's// Long input (1024 chars)privateconststringLongA=MediumA+MediumA+MediumA+MediumA;// 1024 'a'sprivateconststringShortText="Sherlock Holmes lived at 221B Baker Street in London";privateconststringMediumText=ShortText+" and was known as the greatest detective of all time. His companion Dr. Watson chronicled their many adventures together through foggy London nights.";privateconststringLongText=MediumText+MediumText+MediumText+MediumText;// No 'x' chars - for Notonerep [^x]{N}privateconststringNoXShort="abcdefghijklmnopqrstuvwyzabcdefghijklmnopqrstuvwyzabcdefghijklmn";// 64 chars, no 'x'privateconststringNoXMedium=NoXShort+NoXShort+NoXShort+NoXShort;// 256 chars// === Oneloop: greedy single-char loops like a+, a*, [^x]+ ===// These use IndexOfAnyExcept in the optimized pathprivateRegex_oneloopPlus64,_oneloopPlus256,_oneloopPlus1024;privateRegex_oneloopStar256;[GlobalSetup(Target=nameof(Oneloop_Plus_64))]publicvoidSetup_Oneloop_Plus_64()=>_oneloopPlus64=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_256))]publicvoidSetup_Oneloop_Plus_256()=>_oneloopPlus256=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Plus_1024))]publicvoidSetup_Oneloop_Plus_1024()=>_oneloopPlus1024=newRegex("a+",RegexOptions.None);[GlobalSetup(Target=nameof(Oneloop_Star_256))]publicvoidSetup_Oneloop_Star_256()=>_oneloopStar256=newRegex("a*",RegexOptions.None);[Benchmark]publicMatchOneloop_Plus_64()=>_oneloopPlus64.Match(ShortA);[Benchmark]publicMatchOneloop_Plus_256()=>_oneloopPlus256.Match(MediumA);[Benchmark]publicMatchOneloop_Plus_1024()=>_oneloopPlus1024.Match(LongA);[Benchmark]publicMatchOneloop_Star_256()=>_oneloopStar256.Match(MediumA);// === Onerep: fixed-count single-char like a{64}, a{256} ===// These use ContainsAnyExcept in the optimized pathprivateRegex_onerep64,_onerep256;[GlobalSetup(Target=nameof(Onerep_64))]publicvoidSetup_Onerep_64()=>_onerep64=newRegex("a{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Onerep_256))]publicvoidSetup_Onerep_256()=>_onerep256=newRegex("a{256}",RegexOptions.None);[Benchmark]publicboolOnerep_64()=>_onerep64.IsMatch(ShortA);[Benchmark]publicboolOnerep_256()=>_onerep256.IsMatch(MediumA);// === Notonerep: fixed-count not-char like [^x]{64}, [^x]{256} ===// These use Contains in the optimized pathprivateRegex_notonerep64,_notonerep256;[GlobalSetup(Target=nameof(Notonerep_64))]publicvoidSetup_Notonerep_64()=>_notonerep64=newRegex("[^x]{64}",RegexOptions.None);[GlobalSetup(Target=nameof(Notonerep_256))]publicvoidSetup_Notonerep_256()=>_notonerep256=newRegex("[^x]{256}",RegexOptions.None);[Benchmark]publicboolNotonerep_64()=>_notonerep64.IsMatch(NoXShort);[Benchmark]publicboolNotonerep_256()=>_notonerep256.IsMatch(NoXMedium);// === MatchString: literal string matching ===// These use SequenceEqual in the optimized pathprivateRegex_matchStr8,_matchStr16,_matchStr52;[GlobalSetup(Target=nameof(MatchString_8))]publicvoidSetup_MatchString_8()=>_matchStr8=newRegex("Sherlock",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_16))]publicvoidSetup_MatchString_16()=>_matchStr16=newRegex("Sherlock Holmes ",RegexOptions.None);[GlobalSetup(Target=nameof(MatchString_52))]publicvoidSetup_MatchString_52()=>_matchStr52=newRegex("Sherlock Holmes lived at 221B Baker Street in Lo",RegexOptions.None);[Benchmark]publicboolMatchString_8()=>_matchStr8.IsMatch(ShortText);[Benchmark]publicboolMatchString_16()=>_matchStr16.IsMatch(ShortText);[Benchmark]publicboolMatchString_52()=>_matchStr52.IsMatch(LongText);}}

[Copilot]

Pull request overview

This PR optimizes hot-path opcode handling in RegexInterpreter by replacing per-character loops with SIMD-accelerated span operations for left-to-right matching, extending the existing vectorization precedent in the interpreter.

Changes:

• Vectorize literal string matching (Multi / MatchString) using ReadOnlySpan<char>.SequenceEqual.
• Vectorize fixed-count opcodes Onerep and Notonerep using ContainsAnyExcept / Contains for left-to-right paths.
• Vectorize greedy single-char loops Oneloop / Oneloopatomic using IndexOfAnyExcept for left-to-right paths.

[danmoseley]

Real-world impact estimate: Analyzing the 15,817 unique patterns in the regex test corpus (assuming interpreter engine):

• Multi/SequenceEqual is the most broadly impactful: ~38% of patterns contain literal substrings of 8+ chars (one SIMD register width), where vectorization provides clear wins. At 16+ chars it's ~10%.
• Oneloop (a+, x*) appears in ~1% of patterns; actual benefit is input-length-dependent.
• For +/* quantifiers generally, the speedup depends on matched length at runtime — a pattern like [^:]+ could match 1 char or 1000.

Follow-up PR #124630 adds SearchValues-based vectorization for Setloop/Setrep character class opcodes ([a-z]+, [0-9]{4}, etc.), covering an additional ~35% of patterns with explicit character classes (though again, benefit scales with matched length).

[stephentoub]

@MihuBot benchmark Regex

[MihuBot]

See benchmark results at https://gist.github.com/MihuBot/2004009ab9c5dbd509e407cc62b2d5a5

[danmoseley]

MihuBot Benchmark Analysis

Compiled and NonBacktracking paths are entirely unaffected (ratios 0.98–1.02 across all suites), as expected since the PR only modifies interpreter opcodes.

Interpreter regressions flagged by MihuBot

Benchmark	Main	PR	Ratio
Email_IsMatch None	222.5 ns	249.2 ns	1.12
BoostDocs Id=5 None	213.5 ns	236.6 ns	1.11
BoostDocs Id=9 None	70.3 ns	77.3 ns	1.10
MatchWord None	879.5 ns	962.2 ns	1.09
BoostDocs Id=6 None	70.5 ns	75.0 ns	1.06
SliceSlice IgnoreCase None	680.9 ms	717.4 ms	1.05
Backtracking None	814.7 ns	855.4 ns	1.05
Cache 400K/7/15	27.9 ms	31.0 ms	1.11

Investigation: do these hit modified opcodes?

I mapped each regressed benchmark's pattern to the interpreter opcodes it exercises:

• Email_IsMatch^([a-zA-Z0-9_\-\.]+)@... → uses Setloop for character classes — not modified by this PR
• BoostDocs Id=5 (same email pattern) → Setloop — not modified
• BoostDocs Id=9^\d{1,2}/\d{1,2}/\d{4}$ → Setloop/Setrep for \d, One for / — not modified
• BoostDocs Id=6^[a-zA-Z]{1,2}[0-9]... {0,1}... → Setloop/Setrep for char classes; Oneloop only for {0,1} with len≤1 — marginally touched
• MatchWordtempus|magna|semper → alternation + MatchString for 5-6 char literals — touched, but SequenceEqual overhead negligible at this length
• Backtracking.*(ss) → Setloop for .*, MatchString for 2-char "ss" — marginally touched, dominated by backtracking cost
• SliceSlice IgnoreCase (every word, case-insensitive) → IgnoreCase converts single chars to Set opcodes — not modified
• Cache 400K/7/15 → cache lookup benchmark, not pattern-matching bound — not modified

5 of 8 regressions don't exercise any modified opcode. The 3 that marginally touch modified code are dominated by other costs (backtracking, alternation, cache behavior).

Root cause: JIT code layout effects

TryMatchAtCurrentPosition is an ~830-line method with a 40+ case switch. Adding if (!_rightToLeft) branches to 3 case arms changes the JIT-compiled native code layout for the entire method — shifting instruction cache boundaries, branch predictor state, and basic block alignment for all opcodes including unmodified ones. The same effect causes the improvement on \w+\s+Holmes\s+\w+ None (0.89 ratio, 11% faster) and the noise in the IgnoreCase Compiled suite (ReplaceWords 1.28 but SplitWords 0.84 — clearly not real).

These are interpreter-only, sub-microsecond-scale, on shared cloud VMs, affecting unmodified code paths — classic JIT layout noise.

[danmoseley]

build analysis is green - test failures are unrelated. ready for review?

[danmoseley]

MihuBot Results vs. Local Benchmarks

The MihuBot standard benchmark suites (Sherlock, Leipzig, BoostDocs, etc.) don't directly validate the 2x-7x local speedups because they use complex real-world patterns where the hot paths are mostly Setloop/Setrep (character classes) rather than the Oneloop/Onerep/Notonerep/MatchString opcodes modified here, and literal strings in the patterns are short (e.g. Sherlock = 8 chars, where the local benchmarks show only ~1.1x).

What MihuBot does confirm:

• Compiled/NonBacktracking paths are flat (0.98-1.02 ratios across all suites) -- expected since only interpreter opcodes were changed.
• No real regressions -- the flagged interpreter regressions (1.05-1.12x) don't exercise modified opcodes (they hit Setloop/Setrep/cache paths); see analysis above.
• Directionally positive interpreter results:
  • \w+\s+Holmes\s+\w+ None: 0.89 ratio (11% faster) -- plausibly from MatchString on Holmes
  • the None: 0.97, Sherlock Holmes None: 0.98, Sherlock\s+Holmes None: 0.97 -- consistent with small MatchString wins on short strings
  • the\s+\w+ None: 0.97

The local microbenchmarks are the right tool for validating these specific codepaths since they isolate the modified opcodes with long enough inputs to show the SIMD gains.

[danmoseley]

I've reduced this PR to only the MatchString changes, dropping the Oneloop/Onerep/Notonerep vectorization. Here's my reasoning:

Why drop Oneloop/Onerep/Notonerep:

Stephen's right that these are hard to justify for real-world patterns. Analyzing the 15,817 real-world patterns: single-char quantifiers like a+ appear in ~1% of patterns, and fixed-count single-char like a{64} is essentially nonexistent. The 2x-7x benchmark wins require 64-1024 char matches of a single repeated character -- synthetic scenarios where real users would likely use Compiled.

Unlike #124630 (SearchValues for Setloop/Setrep), there's no construction-time overhead here -- these are just match-time IndexOfAnyExcept/ContainsAnyExcept/Contains calls. But the cost is code complexity: adding if (!_rightToLeft) branches in the ~830-line switch method changes JIT code layout for the entire method, creating noise on all opcodes (as the MihuBot analysis showed). Not worth it for ~1% real-world coverage.

Why keep MatchString:

• Coverage: ~38% of real-world patterns contain literal substrings. Every regex with a literal fragment hits this path.
• No construction cost: StartsWith/EndsWith are just SequenceEqual calls -- zero additional work at construction time.
• Simpler code: The original MatchString was 44 lines with a shared reverse char-by-char loop and two post-loop fixup branches. The new version is 27 lines with clear, separated LTR (StartsWith) and RTL (EndsWith) paths. This is a readability win independent of performance.
• No perf regression risk: StartsWith/EndsWith delegate to SequenceEqual internally, so matching performance is equivalent for short strings and better for longer ones via SIMD. The RTL path (previously always char-by-char) now also benefits from vectorization, though RTL matching is rare in practice.

[stephentoub]

thanks

[danmoseley]

/ba-g infra