perf(zql): comparator fast paths + compareBounds null fix

[Karavil]

Note: This PR is part of an upstream contribution effort from the Goblins team (@goblinshq). Co-authored with Claude by Anthropic.

Summary

Multiple comparator optimizations targeting the hottest paths in the IVM pipeline, plus a bug fix for nullable column comparisons.

Motivation

In a production app with 45 parent rows x ~200 related rows across 135 IVM pipelines, comparator functions are invoked millions of times per page render (every BTree node comparison during index scans calls makeBoundComparator, and every row sort calls makeComparator). These optimizations target the innermost loops:

• String comparison: 99%+ of real-world values are ASCII strings. The default compareUTF8 processes full UTF-8 encoding even for simple ASCII, adding unnecessary overhead per comparison.
• Single-key sorts: Most IVM pipeline sorts use a single column. The generic multi-key loop has per-iteration overhead (destructuring, array access) that compounds across millions of calls.
• BTree comparator call depth: makeBoundComparator -> compareBounds -> compareValues -> compareUTF8 is a 4-deep call chain on every BTree node visit. Flattening this into a single compareBoundValue helper eliminates 3 function call frames.

Changes

data.ts

• Add compareStringUTF8Fast(): ASCII fast-path that compares char codes directly, falling back to compareUTF8 only when non-ASCII characters are encountered
• Reorder compareValues() to check strings before nulls (strings are the most common type in practice)
• Add single-key fast path in makeComparator(): for single-column orderings, return a direct comparator avoiding the loop

memory-source.ts

• Bug fix: Add null/undefined guards before delegating to compareValues(). compareValues asserts type homogeneity (e.g., calls assertString(b) when a is a string), but nullable database columns can produce null vs string comparisons that trigger assertion failures.
• Add compareBoundValue() helper: merges sentinel handling (minValue/maxValue), null guards, and type-specific comparison (string via compareStringUTF8Fast, number via subtraction) into a single function. Well within V8 TurboFan's ~460-bytecode inlining threshold, so it gets inlined at call sites.
• Simplify makeBoundComparator() to delegate to compareBoundValue: single-key path is ~2 lines instead of 35, multi-key path also uses compareBoundValue directly (replacing the old compareBounds wrapper).

Expected Performance Impact

These changes primarily reduce CPU time in BTree index scans. In profiling:

• compareUTF8 calls dropped significantly due to ASCII fast-path (most string comparisons resolve without the UTF-8 library call)
• Single-key comparator eliminates loop overhead for the common single-column sort case
• compareBoundValue flattens the 4-deep call chain into 1 function that V8 inlines, eliminating frame overhead across thousands of BTree node visits per fetch

Combined with other IVM optimizations in this series, contributed to reducing page freeze from ~7.7s to <1s across the full optimization series.

Testing

• All existing data and memory-source tests pass
• New tests for compareStringUTF8Fast (ASCII, Unicode, empty, prefix, property-based)
• New tests for makeComparator single-key path (asc, desc, reverse, equality)
• Existing compareValues property test updated to use Math.sign (the ASCII fast-path returns char code differences rather than -1/0/1, but the sign is always correct)

---

Stack Order

This PR is part of a stacked series of IVM performance optimizations. Merge in order:

1. perf(zql): reduce allocations with frozen sentinel and object reuse #5609 - Allocation reduction
2. perf(zql): cache primary index key, pkConstraint, and index lookups #5610 - Index caching
3. perf(zql): comparator fast paths + compareBounds null fix #5611 (this PR) - Comparator fast paths
4. perf(zql): fuse fetch pipeline, add PK fast path, reduce allocations #5612 - Fetch pipeline fusion

Independent PRs (no conflicts): #5607 (BTree iterators), #5608 (Join optimizations)

[vercel]

Someone is attempting to deploy a commit to the Rocicorp Team on Vercel.

A member of the Team first needs to authorize it.