Revert "Simplify RegexInterpreter (#124628)" by danmoseley · Pull Request #126221 · dotnet/runtime

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

Closes#126156

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

Closes#126156

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

Closes#126156

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

Closes#126156

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

Closes#126156

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

Closes#126156

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

danmoseley · 2026-03-27T19:22:48Z

Revert "Simplify RegexInterpreter (#124628)"

This reverts commit f194942 from #124628.

Closes#126156

#124628 replaced the char-by-char loop in RegexInterpreter.MatchString with StartsWith/EndsWith. This caused a 7-11% regression on arm64 (AmpereUbuntu) for Perf_Regex_Industry_Leipzig patterns that exercise MatchString heavily via alternation:

.{0,2}(Tom|Sawyer|Huckleberry|Finn) None: 5.01s to 5.56s (1.11x)
.{2,4}(Tom|Sawyer|Huckleberry|Finn) None: 5.16s to 5.51s (1.07x)

These patterns call MatchString millions of times with short strings (3-11 chars: "Tom", "Finn", "Sawyer", "Huckleberry") where Slice + StartsWith + SequenceEqual dispatch overhead exceeds the original tight loop cost, with no SIMD benefit at those lengths.

The MihuBot x64 results for the original PR showed the same patterns regressing at 1.03-1.04x, but this was overlooked during review.

This reverts commit f194942.

dotnet-policy-service · 2026-03-27T19:24:03Z

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

danmoseley · 2026-03-27T19:24:10Z

Verified locally that this recovers the regression.

Copilot

Pull request overview

Reverts the RegexInterpreter.MatchString change from #124628 that replaced the per-character literal match loop with StartsWith/EndsWith, addressing a measured interpreter performance regression on Linux/arm64 for short literal alternations (e.g., Leipzig benchmarks).

Changes:

Restore the original tight per-character comparison loop in RegexInterpreter.MatchString.
Avoid Slice + StartsWith/EndsWith overhead in hot paths where literals are short and invoked millions of times.

stephentoub · 2026-03-27T19:31:02Z

This reverts commit f194942 from #124628.

Just to confirm, it reverts the whole PR, right? Nothing that merged in that PR remains?

danmoseley · 2026-03-27T22:10:16Z

Yes, complete git revert.

danmoseley · 2026-03-28T01:41:47Z

/ba-g unrelated

Revert "Simplify RegexInterpreter (dotnet#124628)"
04c14cf
This reverts commit f194942.

CopilotAI review requested due to automatic review settings March 27, 2026 19:22

github-actionsBot added the area-System.Text.RegularExpressions label Mar 27, 2026

dotnet-policy-serviceBot assigned danmoseley Mar 27, 2026

danmoseley requested a review from stephentoub March 27, 2026 19:23

Copilotstarted reviewing on behalf of danmoseley March 27, 2026 19:23 View session

CopilotAI reviewed Mar 27, 2026
View reviewed changes

stephentoub approved these changes Mar 28, 2026
View reviewed changes

danmoseley merged commit fb8b250 into dotnet:mainMar 28, 2026
92 of 101 checks passed

danmoseley deleted the revert-124628 branch March 28, 2026 01:42

dotnet-maestroBot mentioned this pull request Mar 28, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#5757
Merged

github-actionsBot locked and limited conversation to collaborators Apr 27, 2026