pretable's interaction latency is ~2x TanStack's on S2 sort and filter

[blove]

Measured in #451 (status/milestones/2026-08-16-s2-mount-and-interaction.json), on a quiet machine, like-for-like on wrapping and pinning.

Interaction latency in ticks of a 120Hz frame, n=7 per cell:

script	tanstack	pretable
sort	2–5t (17–42ms)	6–8t (50–67ms)
filter-metadata	2–4t (17–33ms)	5–7t (42–58ms)
filter-text	1–4t (8–33ms)	6–7t (50–58ms)

pretable centres on 7 ticks (58ms), TanStack on 3–4 ticks (25–33ms). Consistent across three structurally different interactions and 21 repeats each, with barely overlapping distributions — so this is not the sampling artifact that invalidated the scroll medians in #450.

Where it probably is not

Rendering. pretable settles with the fewest DOM nodes of the four adapters:

	pretable	tanstack	ag-grid	mui
rendered rows at settle	7–8	6–7	16–18	11
DOM nodes at settle	100–107	294–335	474–506	1180

Doing the least DOM work and still losing to two of the three points at the row model — filtering and sorting 3,000 rows — rather than at paint.

What would settle it

A CPU profile sliced to the interaction window, which nobody has taken:

PLAYWRIGHT_PERF_TRACE=1 pnpm bench:matrix --adapters=pretable --scenarios=S2 --scripts=sort --scale=hypothesis --repeats=1

then node scripts/analyze-cdp.mjs <trace> <bundle>.js.map --window=interaction. Note the window flag: the full-trace view is dominated by mount work that does not count against interaction_latency_ms.

Worth knowing before optimising: #388 filed a scroll cost as an accuracy-vs-speed trade and the profile showed it was neither — it was redundant grapheme segmentation. The frame this issue names may likewise not be where it looks.

Caveat

interaction_latency_ms is frame-quantised, so pretable's 7 ticks and TanStack's 4 differ by three frames, not by "33ms" precisely. The gap is real and reproducible; the exact millisecond figure is not the thing to optimise against.

[blove]

Took the profile this issue asks for. It does not confirm the hypothesis, and it is under-powered — recording both so the next attempt starts further along.

pnpm bench:matrix --adapters=pretable --scenarios=S2 --scripts=sort --scale=hypothesis --repeats=1   (PLAYWRIGHT_PERF_TRACE=1)
node scripts/analyze-cdp.mjs <trace> <bundle>.js.map --window=interaction

Window: interaction (36.31 ms)
Total sample time in window: 88.84 ms across 123 unique nodes

  57.9%  (program)
   2.4%  getBoundingClientRect
   2.1%  packages/react/dist/index.mjs:4386
   1.4%  packages/row-model/dist/persistent/persistent-map.js:157
   1.2%  packages/row-model/dist/compiled-query.js:823
   1.2%  packages/row-model/dist/persistent/persistent-map.js:221

--window=settle (51.85ms) gives the same shape: (program) 55.4%, nothing else above 2.2%.

Two things this says

There is no JS hotspot to attack. Compare #388's scroll trace, where segmentGraphemes was 16.2% and (program) 20.6% — one frame you could point at. Here the largest attributed frame is 2.4% and the row-model frames sum to roughly 5ms. The "engine, not paint" hypothesis in the issue body is not supported by this: (program) is V8's bucket for time outside any JS frame, so more than half the window is GC, compilation, or browser-internal layout/paint work.

But the sample is too thin to conclude that either. The CPU profiler samples at roughly 1ms, so a 36ms window yields on the order of 36 samples — 123 unique nodes across them. (program) dominating a sparse profile is as consistent with under-sampling as with genuinely diffuse work. The reported "88.84ms of sample time in a 36.31ms window" is itself a sign the accounting is not straightforward here.

So: I am not able to say where pretable's interaction time goes, and neither the issue's hypothesis nor its refutation is established.

What the next attempt should do differently

• Pool several repeats rather than profiling one. One interaction is too short for a 1ms sampler.
• Profile TanStack's sort interaction the same way and difference the two. The question is not "what does pretable do" but "what does pretable do that TanStack does not", and a single-adapter profile cannot answer that.
• Consider a larger scale (target) to lengthen the window, accepting that it changes what is being measured.

The 2x latency gap in #451 stands — it is reproducible across three scripts and 21 repeats each. Only the explanation is open.

[blove]

Correcting my previous comment. It was wrong, and the reason is a bug in the analyzer rather than in the profile.

scripts/analyze-cdp.mjs restarted the sample clock at every ProfileChunk, so every --window= slice this repo has produced was misattributed. Fix in #454. The (program) at 57.9% I reported was an artifact of samples being displaced into the window from elsewhere.

Same trace, same window, corrected:

Window: interaction (36.31 ms)
Total sample time in window: 37.06 ms across 120 unique nodes     (was 88.84ms)

   5.7%  getBoundingClientRect
   5.1%  packages/react/dist/index.mjs:4386
   4.6%  (garbage collector)
   4.2%  getBoundingClientRect
   3.8%  (program)                                                 (was 57.9%)
   3.3%  packages/row-model/dist/persistent/persistent-map.js:157
   2.8%  packages/row-model/dist/compiled-query.js:823
   2.8%  packages/row-model/dist/persistent/persistent-map.js:221

So the issue body's hypothesis was right after all

The interaction window is almost entirely attributed JavaScript — 33.9ms of a 36.3ms window, with (program) at 1.4ms and GC at 1.7ms. It is not browser layout or paint time. "Engine, not paint" stands.

Sliced the same way against TanStack's sort on the same tree and machine:

	window	attributed JS	distinct functions
pretable	36.3ms	33.9ms	70
tanstack	15.2ms	15.7ms	22

So pretable does roughly 2.2× the JavaScript work across ~3× as many distinct functions. That is the 2× latency gap, and it is diffuse: no single frame exceeds 5.7%, and the largest identifiable cluster is getBoundingClientRect at ~10% (3.7ms) followed by the persistent-map and compiled-query work.

What that means for fixing it

There is no hotspot to delete. The gap is architectural — pretable runs more code, in more places, per interaction — so closing it is a design question rather than an optimisation. The two concrete leads worth pulling first:

• ~10% in getBoundingClientRect inside a 36ms interaction window. Measurement during an interaction is a classic avoidable cost if any of it is re-reading geometry that is already known.
• persistent-map + compiled-query at ~9% combined, which is the row-model doing the sort over 3,000 rows. Expected work, but worth comparing against TanStack's createSortedRowModel at 1.9%.

Neither is established as the answer; both are now measured rather than guessed.

[blove]

Chased the getBoundingClientRect lead from my previous comment. It is mostly not pretable, so that lead was misdirected — correcting it, and the correction makes the underlying gap larger rather than smaller.

Resolving the two call paths through the source map:

ms	path	whose
2.12	measureRowSetChange → sample → sampleVisibleRows → getViewportContentBounds → gBCR	the benchmark harness
1.57	measureRenderedRowHeight → measureCellContentHeight → gBCR	pretable

So of the ~3.7ms I flagged as "a classic avoidable cost", 2.12ms is the settle detector observing, and only 1.57ms is pretable — and that 1.57ms is measureRenderedRowHeight, which is load-bearing for variable row heights rather than obviously wasteful. Drop that lead.

The harness cost is not symmetric, and the gap is worse than reported

Classifying every sample in the interaction window by resolved source:

	sampled	harness	adapter work
pretable	37.1ms	3.25ms (8.8%)	33.8ms
tanstack	15.7ms	5.44ms (34.6%)	10.3ms

The detector walks rendered rows, and TanStack renders 640 cells to pretable's 72 — so it pays ~8.9x the observation cost, inside its own measured window. Filed separately as #455.

Correcting for it:

• reported latency ratio 2.4x → adapter-work ratio 3.28x

pretable does roughly 3.3x TanStack's JavaScript work on a sort, not 2x. The reported figure was flattered by pretable rendering the least DOM of the four and therefore paying the least observer tax.

Where that leaves the leads

• getBoundingClientRect — mostly the harness. Dropped.
• persistent-map + compiled-query, ~9% combined — the row model sorting 3,000 rows, against TanStack's createSortedRowModel at 1.9%. Still the strongest lead and now the only one.
• The rest is diffuse: 70 distinct functions against TanStack's 22, nothing above 5.7%. That shape says the gap is architectural — more code running in more places per interaction — rather than one hot function.

Three corrections on this issue now, each from better measurement rather than new opinion: the analyzer was mis-slicing (#454), the largest frame was the observer (#455), and the gap is bigger than first reported. The one thing that has not moved is that the gap is real, reproducible, and JavaScript-bound.

[blove]

Deep-research pass complete: five parallel code readers (pretable's sort pipeline, TanStack's installed 9.1.2, the bench evidence, the capability inventory, metric fairness), two adversarial verifiers, plus two experiments nobody had run. Full answer to "does closing this close the competition gaps":

The gap is a scaling curve, not a constant

New measurements (S2 sort, this machine, quiet):

loaded rows	pretable	tanstack
750	25–33ms — tied	~25–35ms
3,000	~58ms (2x)	~25–33ms
50,000	never settles, >400ms (#457)	~33ms, settles ~100ms

TanStack is flat because its sort is one synchronous Array.sort over cached values in the React render — verified in the installed package, five refutation attempts, no yield primitive anywhere in table-core. pretable's cost scales with loaded rows because every transition re-evaluates every row through the compiled query (accessors + ALL filters, cold per-plan cache) and rebuilds two persistent structures row-by-row.

Decomposed (row model timed directly in Node, sweeping transitionBudgetMs)

3,000 rows:  41.3ms @ default 0.25ms budget -> 21.3ms @ 4ms   (yield tax ~46%)
50,000 rows: 589.9ms @ default              -> 515.4ms @ sync (work dominates)

So this issue's 2x at hypothesis scale is roughly half scheduler duty-cycle (DEFAULT_BUDGET_MS = 0.25 buys ~0.25ms of work per ~0.25ms hop) and half per-row transition work (~10µs/row). The levers, with measured ceilings, are in #457: budget tuning (cheap, closes most of the 3k gap), sort-only metadata reuse, bulk rebuild for full re-sorts.

What the architecture buys — and why the metric can't see it

The cooperative transition publishes nothing until complete and never blocks the main thread; TanStack blocks for its full sort. interaction_latency_ms awards zero credit for that — and the interaction path collects no long-task metric at all (#458), so the benefit pretable pays 2x for is structurally invisible in every table published so far. At 50k TanStack's block is only ~33ms, so the "sync collapses at scale" defence does NOT hold at pretable's own target scale; it would take ~500k+ rows or expensive comparators before blocking becomes the story.

Does closing this close the competition gaps?

The measured performance gaps: mostly yes. Post-#454/#455/#456 the S2 picture is — pretable wins scroll consistency (14/14 at one tick), anchor stability (0 vs TanStack's 592px), DOM totals, and beats MUI/AG Grid on every interaction; it loses interactions to TanStack (this issue) and mount to TanStack (82.5 vs 64.5ms). Fixing the two root causes here flips the biggest LOSS cell; mount is then the only remaining performance loss, and it is 18ms against the least-featured competitor.

The competition overall: no — and that is the finding. The capability inventory (verified against installed packages) is where the moat actually is: row grouping is AG Grid Enterprise and MUI Premium; column pinning is MUI Pro; streaming has no TanStack primitive; server-side windowing/eviction, typed editors, clipboard, CSV export ship in pretable and are absent, paid, or DIY elsewhere. TanStack — the only competitor that wins any measured cell — is headless: its 1.10 nodes/cell and its 64.5ms mount are for markup you write yourself, and its 592px anchor drift is what its virtualizer does by default. A buyer comparing "grid products" is not choosing between pretable and TanStack's numbers; they are choosing between pretable and building a grid on TanStack.

So: fix this issue via #457's levers because a 2x interaction loss to the headless baseline is not defensible; fix #458 so the trade pretable makes is measurable at all; and treat #457's target-scale result as the real emergency — the primary wedge scenario's own scale currently cannot complete a sort inside the harness window.

One stale-comment fix also fell out: packages/bench-runner/src/index.ts:486 claims TanStack ships no grouping row model; installed v9.1.2 ships createGroupedRowModel. Task chip filed.