Faster codemirror search match counting - #612

Summary

Typing into the response search panel (Cmd+F) lags badly on multi-megabyte bodies. Fixes Improve search performance for large responses.

The panel's own search is viewport-bounded and fine. The match count beside it isn't: searchMatchCount.ts ran SearchCursor over the entire document on every query change and every selection change — ~400ms per keystroke on a 5MB response, and the 9999-match cap stopped helping as soon as the query got specific enough to have few matches. The JSONPath filter field is not involved; it applies on Enter.

Where the time actually goes

Measured on 5M characters:

91% of the cursor's time is one ICU call per code point. The same Unicode work in bulk is 77× cheaper, so no amount of caching, capping or debouncing makes a cursor-based count fast. It has to stop normalizing a character at a time. (@codemirror/search 6.7.1 has no match-count API to lean on — it exports the two cursors and SearchQuery, and the discuss thread is people writing this loop themselves.)

Implementation

normalizeDoc rewrites the document the way the cursor does — NFKD, then a case fold unless the search is case-sensitive — but once per document instead of once per character. Each distinct character is normalized once and the answer reused; runs of ASCII never reach ICU. Doing it per character rather than over the whole string still matters: it stops NFKD from reordering combining marks across characters, and stops toLowerCase from applying Greek final-sigma rules the cursor doesn't.

Characters whose normalized form has a different length are recorded as expansions, so matches found with indexOf map back to document offsets — floor for the start, ceil for the end, which is what the cursor reports when a match begins or ends inside a decomposed character.

Matches are kept per document and query, so moving the selection looks up the current one instead of scanning again. Regexp and whole-word queries still go through the cursor.

Measurements

Synthetic 5MB JSON, time to count one query:

Plus a one-time normalized copy on the first keystroke: 17ms (ASCII), 17ms (accented), 40ms (CJK-heavy).

Tests

The offset mapping is the part that can go quietly wrong, and only on input nobody thinks to write a case for — so the input is generated. A seeded fuzz test builds documents from an alphabet of precomposed and decomposed accents, ligatures, ellipses, NBSP, İ, Σ/ς, CJK, emoji, roman numerals, fullwidth letters, bare combining marks and backslashes, then asserts the counter's matches equal SearchCursor's exactly, from and to, in both case modes.

It earned its keep immediately — it found both correctness rules in the diff, neither of which I would have reasoned my way to:

• a match ends on a whole code point however the query was cut (a lone surrogate in the query)
• scanning resumes past the character a match ended inside, so . counts … once rather than three times

Before merging I ran it at 20,000 rounds × 5 seeds × 2 case modes — 200,000 generated documents, exact agreement throughout. It's committed at 400 rounds so it stays cheap in CI.

Alongside that: overlap skipping, \n unquoting vs literal, the 9999 cap, current-match lookup, the regexp/whole-word handover, and match reuse across a selection-only transaction. vp test 519/519, tsc --noEmit and oxlint clean.

Notes

Worth reporting upstream — SearchCursor could normalize per chunk, or skip it when both sides are ASCII, and every CodeMirror user counting matches would get this for free.

🤖 Generated with Claude Code