[sebastienros]

Jint now runs every script RegExp on GregsEx's ECMAScript flavor, so every unique pattern compiles on a cache miss. Reviewing sebastienros/jint#4300 (item 5) found i-flag and \p{...} patterns compiling 10-16× slower than Jint's previous engine. This PR fixes the causes.

Causes and fixes

• \p{L} was ~300 µs to compile, and the tables were not the cause. EcmaUnicodeData.GetIntervals returns a span over the generated table. The cost was ResolvedSet.AddRange, which found each new range's position by scanning from the first range, so loading a property's ~700 sorted ranges was quadratic: about 240,000 compile-work units for \p{L}. It now appends directly past the last range and otherwise uses a binary search. The same fix takes the fold of a complement under iu ([^x]) from 1.7 ms to about 60 µs. With this fixed, a per-property cache wasn't needed.
• Legacy i fast sets (the folded bitmap from ECMAScript: cut per-search and case-insensitive costs found under Jint #3):
  • the SearchValues are built by walking the bitmap's set bits instead of testing all 65,536 code units;
  • the folded bitmap is corrected only at mappings whose source or target is inside the class. Before, it binary-searched the class for each of the ~1,400 legacy mappings. A by-target copy of the legacy table is cached per EcmaCaseTables;
  • the ASCII masks are read from the bitmap's first two words instead of 128 table lookups.
• WithoutCaselessIgnoreCase rebuilt a set of ~2,500 case-mapped points on every compile. It is now cached per EcmaCaseTables (one slot per mode), the same way as InverseFolds.
• Identical classes share one EcmaFastSet. Set nodes with the same members and case mode now share one instance. Strings and the (?i:) modifier keep sets apart.
• FirstChars stops early on a class with more BMP members than its 2,048 cap. Before, it hashed 2,049 characters of \p{L} and then gave up.
• I did not drop the 8 KiB bitmap for ASCII-only sets. About ten plan and executor call sites read BmpBits is null as "no exact bitmap", and the zeroed allocation costs about 0.5 µs.

The source generator compiles EcmaAccelerator.cs for netstandard2.0, where BitOperations is internal. A stand-in is added to Netstandard2Polyfills.cs.

Per-compile timings

The table measures the two stages Jint runs on a cache miss: EcmaCompiler.TryCompile and EcmaExecutorFactory.TryCreate (which builds the EcmaAccelerator). Unicode 17.0 tables, Release, best of 7 rounds of 2,000 compiles. Host: Apple Silicon (arm64) macOS 15.8.1, .NET 10, run in a quiet session after the test suite had finished.

Before (origin/main dc455e9):

Pattern	Flags	Compiler µs	Executor factory µs	Total µs
[a-z]+@[a-z0-9.]+\.[a-z]{2,}	IgnoreCase	2.0	98.3	100.3
[À-ɏ][a-zͰ-Ͽ]+\w*	IgnoreCase	33.4	92.8	126.2
\p{L}+\p{Nd}*	Unicode	281.2	25.3	306.5
[a-z]+@[a-z0-9.]+\.[a-z]{2,}	None	1.0	2.6	3.6
\w+\s[^x]+	IgnoreCase, Unicode	1663.2	9.1	1672.3
[\p{L}--[a-z]]+	UnicodeSets	532.1	4.1	536.2
"(?:[^"\\]|\\.)*"	None	1.2	2.5	3.6

After:

Pattern	Flags	Compiler µs	Executor factory µs	Total µs
[a-z]+@[a-z0-9.]+\.[a-z]{2,}	IgnoreCase	2.9	11.4	14.3
[À-ɏ][a-zͰ-Ͽ]+\w*	IgnoreCase	8.7	16.3	25.0
\p{L}+\p{Nd}*	Unicode	12.8	3.4	16.2
[a-z]+@[a-z0-9.]+\.[a-z]{2,}	None	1.1	1.8	2.9
\w+\s[^x]+	IgnoreCase, Unicode	61.1	6.1	67.2
[\p{L}--[a-z]]+	UnicodeSets	18.7	2.6	21.4
"(?:[^"\\]|\\.)*"	None	1.2	2.3	3.5

Tests

New tests in JintRegressionTests:

• FoldedClassMembershipFollowsCanonicalizeOnEveryCodeUnit: 14 classes under i, no flags and u, for Unicode 16 and 17. For every code unit it checks that the bitmap, the ASCII masks and the SearchValues agree with Canonicalize.
• ClassesWithTheSameMembersAndCaseModeShareOneFastSet, including a (?i:) modifier that must stay separate.
• CasedCodePointsAreBuiltOncePerCaseTables: the cache is per Unicode version (U+A7CE/U+A7CF are new in 17.0).
• PropertyClassesLoadInLinearWork: the loaded ranges equal the table's, and the compile work stays linear. On main, \p{L} charges 240,451 work units and fails this test.
• OutOfOrderClassRangesMerge.

dotnet test GregsEx.slnx -c Release on 185b1f5: 24,543 passed,## Variable-length backtracking frames (d576d26)

A choice frame in EcmaExecutor copied the whole task stack (TaskWidth * taskCapacity ints) and every register, so /"(?:[^"\\]|\\.)*"/ needed about 157 workspace ints per character of a string literal. A frame now keeps only what it must undo:

• Tasks: copy-on-pop. The first time a slot under the top choice's height is popped, its value goes to a task trail. The stack moves one slot at a time, so a frame's segment is contiguous and needs no slot numbers. The task an alternative, lazy body or set string resumes with is stored in the same segment.
• Registers: (register, value, stamp) entries. A per-register stamp holds the depth it was last trailed at, so each register is trailed once per frame. An undo puts the stamp back.
• Positive lookahead success: the dropped choices' task trail is truncated (the body cannot pop below its AssertionEnd). The register trail is compacted to one oldest entry per register, because captures set inside the assertion survive it.

Sizing stays affine in frameCapacity, which Jint's growth plan relies on. Per frame: 6 ints of choice, 12 ints of task-trail allowance, and 3 × min(2·groups, 4) ints of register-trail allowance (none without groups). The allowances go into pools that every frame draws from. Running out of choice frames or of either pool is still WorkspaceCapacityExceeded, never growth. GetRequiredCapacity/ComputeAdmittedFrames publish the new equations, and docs/specs/ecmascript.md states the rule.

Longest input on Jint's 64 MiB ceiling

These use JintRegExpEngine's own sizing (16 Mi ints, frames grown to the most that fit, MaxFrames = 1 << 22). The baseline reproduces the review's figures.

Pattern, input	ints/frame before → after	Longest match before	Longest match after
"(?:[^"\\]|\\.)*", "aaa…"	102 → 18	82,239	466,030 (5.7×)
"(?:[^"\\]|\\.)*", literal with escapes	102 → 18	106,912	605,840
(a|b)*c, abab…c	92 → 30	121,572	372,823 (3.1×)
(?:a|b)*c, abab…c	78 → 18	143,392	621,374 (4.3×)

A 1 MB plain literal still exceeds 64 MiB: it needs about 28 ints per character, against 157 before.

Workspace and time (Stopwatch harness, best of 5, Apple M-series arm64, .NET 10, minimal admitted frames)

Case	ints/char before → after	time before → after
quoted string, 1 MiB	156.9 → 27.7	48.9 → 27.0 ms
quoted string, 64 Ki	156.9 → 27.7	1.92 → 1.69 ms
((a)|b)+c, 256 a + c	212 → 60	13.4 → 15.0 µs
((a)|b)+c, bbaaac	176 → 63	388 → 413 ns
(a|b|c)*d, 64 Ki	208 → 60	5.61 → 4.34 ms
(?:(?=(\w))\w)+!, 4 Ki	104 → 30	244 → 227 µs
(\w+)\s(\w+)	25 → 14	237 → 147 ns

ReadmeBenchmarks (BDN, README recipe: --iterationTime 200 --warmupCount 3 --iterationCount 3), ECMAScript interpreted, 0 B allocated before and after:

Method	before	after
ShortIsMatch	276.5 ns	279.8 ns
LongIsMatch	6,382 ns	6,495 ns
ShortCaptures	399.2 ns	418.9 ns

Capture-heavy short searches cost up to about 5% more: they trail registers that used to be copied in one block. These are noisy ShortRun-style numbers.

Tests

• AQuotedStringLiteralReservesItsTrailNotACopyOfTheStackPerFrame pins the reservation below 32 ints per character for a 64 Ki literal. It was about 163 before.
• TrailedCapturesRollBack: 10 capture-rollback witnesses through positive and negative lookaheads, lazy and greedy repeats, and quantified assertions. They run at a 64-frame reservation, and the expected results were checked against Node 24.4 (V8 13.6).

dotnet test GregsEx.slnx -c Release on d576d26: 24,554 passed, 0 failed, in two consecutive runs. In two other full runs, CompiledContractTests.MatchingAllocatesNothing reported 8,136 bytes. That test drives the RegularCore compiled (FEC) lane, which this change does not touch, and it passes in isolation, so it looks like an allocation flake under parallel load.

te change.

🤖 Generated with Claude Code