feat(bench): make the group script comparative against TanStack - #477
Merged
Conversation
The bench-runner gate claimed "TanStack Table ships no row-grouping row model of its own" and excluded it from every grouping script. That was stale: the installed @tanstack/table-core 9.1.2 ships createGroupedRowModel, rowAggregationFeature and createExpandedRowModel in the free package. The only grids whose grouping is genuinely paywalled are AG Grid (Enterprise) and MUI (Premium), and they stay excluded on that stated ground. The tanstack adapter now registers the three features plus the grouped and expanded row models — unconditionally at module scope, gated entirely by state, the same shape as pinning (#413). A `group` plan derives `grouping` from `plan.rowGroups` with everything expanded, which is the state the plan's resultRowCount arithmetic (leaves + one group row per key) describes; group rows render with the harness's own row attributes so the settle signature treats them as rows. Aggregation parity is the part that keeps the comparison honest: pretable's adapter deliberately attaches an "avg" aggregate to every numeric column so the aggregation stage is costed, and TanStack's aggregation is lazy — a grouped render that never reads the aggregated cells would skip the work entirely and flatter it. So numeric columns get `aggregationFn: "mean"` and the group rows RENDER the aggregate, forcing the computation inside the measured window. `group-expand` and the grouped streaming scripts stay pretable-only, and the gate now states the real reason — their setup and trigger run through pretable-specific machinery in bench-app.tsx — instead of the capability claim the old comment got wrong. First comparative run (S2 hypothesis, 5 repeats each, quiet machine): both adapters complete with exactly the plan-predicted 3004 rows and zero long tasks; pretable 58-66ms, tanstack 15-26ms — the same ~2-3x interaction pattern as sort and filter (#452), now with grouping measured like-for-like. Mutation-checked: dropping the aggregate, never deriving the grouping state, grouping unconditionally, and reverting the gate each redden exactly the test built to catch them. 158 bench tests, 16 runner tests, typecheck, lint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
Vercel preview readyPreview: https://pretable-mxa3emj0q-cacheplane.vercel.app Updated automatically by the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bench-runner gate excluded TanStack from every grouping script on the claim that it "ships no row-grouping row model of its own." That was stale: the installed
@tanstack/table-core9.1.2 shipscreateGroupedRowModel,rowAggregationFeatureandcreateExpandedRowModelin the free package. The grids whose grouping is genuinely paywalled are AG Grid (Enterprise) and MUI (Premium) — they stay excluded, on that stated ground.What changed
groupplan derivesgroupingfromplan.rowGroups, everything expanded; group rows carry the harness's row attributes so the settle signature treats them as rows."avg"to every numeric column so the aggregation stage is costed, and TanStack's aggregation is lazy — a grouped render that never reads aggregated cells would skip the work and flatter it. Numeric columns getaggregationFn: "mean"and the group rows render the aggregate, forcing the computation inside the measured window.tanstackforgrouponly.group-expandand the grouped streaming scripts stay pretable-only with the reason corrected to the truth — their setup/trigger run through pretable-specific machinery inbench-app.tsx(waitForGroupedRowModel,grid.rowModel.setGroupExpanded) — rather than the capability claim the old comment got wrong.First comparative grouping numbers
S2
hypothesis, 5 repeats each, quiet machine (idle 88%):Both land on exactly the plan-predicted count (3000 leaves + 4 groups), which is the settle detector's row-count check passing on the plan's own arithmetic — the grouped+expanded flat model and pretable's interleaved model agree. The ~2–3× latency pattern matches sort/filter (#452); grouping is now part of that same story rather than an untestable claim.
Verification
Both directions at the unit layer (group rows + rendered means with a plan; byte-identical ungrouped render without one), and the runner matrix test updated to the new contract — including asserting the tanstack
group-expandrejection says "plumbing", because repeating the stale capability claim is exactly what the old test did.Mutation-checked, each caught by the guard built for it:
158 bench tests, 16 runner tests, typecheck, lint, format.
Follow-up
group-expandcomparator plumbing (a comparator-generic pre-window setup + toggle handle in bench-app) is filed separately — it's an app-machinery change, not an adapter one.🤖 Generated with Claude Code