Regex perf lever 3: drop RegexOptions.ECMAScript (~1.2x) — needs Test262 gating (semantics-sensitive)

[nickna]

Summary

Deferred perf lever 3 from the regex perf work (PR #887, levers 1+2 shipped). A/B profiling showed RegexOptions.ECMAScript is itself a ~1.2× tax vs default on the benchmark workload — i.e. dropping the ECMAScript option would speed guest-facing regex by ~1.2×.

Why deferred

RegexOptions.ECMAScript changes regex semantics, not just speed, so removing/replacing it is correctness-sensitive. It must be gated behind a full Test262 RegExp run before merge — the regex corpus is exactly where a semantics change would surface.

Notes

• Levers 1 (Regex.EnumerateMatches, no Match/Group alloc) and 2 (RegexOptions.Compiled) already shipped, taking compiled-vs-Node from 3.20× → 1.61×.
• The .NET ceiling on this workload is still ~2.3× off Node (Regex.Replace throughput is V8 Irregexp's genuine residual edge); flags alone can't fully close it, so this lever is incremental.
• Run Test262 one mode at a time (--filter "FullyQualifiedName~Test262InterpretedTests") and build SharpTS.Test262.Worker -c Release first — see the test262 runner notes.

Part of epic #856.

[nickna]

Phase 0 (go/no-go) result: the lever has decayed to ~0× on current .NET — recommend parking/closing

Before doing the semantics-risky rewrite, I re-measured the win end-to-end through the actual SharpTS compiled pipeline on current .NET 10, by flipping RegexOptions.ECMAScript → None in both the interpreter runtime type and the compiled emitter (apples-to-apples: same corpus, same dispatch, same JIT path — only the options bit changed). The benchmark patterns (\w+@\w+\.\w+, \d+, day \d+) have no \b/named-groups/forward-refs, so the flip is semantically safe for the measurement.

regex.ts (min ms, best of 5, N=10000):

Path	ECMAScript	Default (None)	Speedup from dropping
whole-benchmark	4.66	4.645	~1.00×
isolated match (/\w+@\w+\.\w+/g)	3.18	3.18	1.00×
isolated replace (/\d+/g)	1.79	1.79	1.00×
isolated test (/day \d+/)	0.0001	0.0001	1.00×

No measurable benefit on any path. A 1.2× tax would show as e.g. match 3.18→3.82 — easily visible against this noise floor; it isn't there.

Why the ~1.2× from PR #887 no longer reproduces

• That A/B ran on an earlier .NET preview; .NET 10's regex engine appears to have closed the ECMAScript-vs-default gap for these patterns.
• The hot match path is now EnumerateMatches (lever 1 from Regex perf: close the compiled-mode gap to Node (EnumerateMatches + Compiled + construction cache + literal hoisting) #887), which is option-insensitive here.
• (A raw-Regex microbench initially suggested replace/test wins of ~1.7×, but that was a JIT/tiering ordering artifact — the in-pipeline flip, which holds everything else constant, shows nothing.)

Recommendation

Park or close this issue. Dropping ECMAScript is genuinely correctness-sensitive — it changes \b/\B word boundaries (Unicode vs ASCII), forward-reference handling, and the $0N substitution edge — and would require a \b-lookaround rewrite, a forward-ref fallback, the two-place runtime↔IL sync, and a full Test262 RegExp gating cycle. Taking on that risk for zero measurable gain on current .NET isn't worth it. If a future .NET regresses ECMAScript-mode perf, this can be revisited — the rewrite approach is sketched and the \b lookaround equivalent is verified.

Pivot

The same profiling showed the match path is ~96% engine-scan-bound (the .NET-vs-Irregexp residual #856 acknowledges), but it also surfaced a clean, semantics-neutral allocation win: String.match/matchAll built an intermediate List<string> and copied it element-by-element into a List<object?>. Removing that → #941 (match-path mean −4.5%, −263 KB/call). That's a real win on current .NET, unlike this lever.