perf(bench): fix 10K fixture isolation in createNested and createSortable

[sridhar-3009]

Summary

Closes #259.

Ten-thousand-item mutation benches were folding O(n) onboard setup into every measured iteration. Since onboarding 10K items costs ~16ms (same order as the operation under test), the measured time was dominated by fixture setup rather than the operation being benchmarked. This caused inaccurate 'slow' tier badges in the docs metrics pipeline.

Changes

createNested/index.bench.ts

open/close operations (10K):

• open() on an already-open node and expandAll() on an already-expanded tree are idempotent at state level — Set.add() is a no-op when the id is already present.
• collapseAll() on an already-collapsed tree spreads an empty openedIds set and does nothing.
• Replaced fresh-per-iteration 10K fixture with a shared pre-built fixture per describe block. Measures the O(depth) guard check / O(n) scan in isolation.

selection operations (10K):

• selectAll() and select(root) on an already-fully-selected tree cause no state changes but still perform the full O(n) descendant traversal.
• Replaced fresh-per-iteration 10K fixture with a shared pre-selected fixture. Measures cascade traversal cost without onboard setup noise.

createSortable/index.bench.ts

move operations (10K):

• Shared fixtures with alternating targets: odd iterations move forward, even iterations restore (e.g. index 5000 → 5001 → 5000 → …). Both directions have identical O(n) map-rebuild cost.

swap operations (10K):

• swap(A, B) is self-inverting: two consecutive calls return to the original state. One shared fixture, called per iteration.

reorder operations (10K):

• Alternating between PERMUTATION_10K (reversed) and PERMUTATION_10K_ORIG (original order). Each direction is a full O(n) reindex.

events overhead (10K):

• Same alternating-move pattern as move operations. Listener remains attached across iterations so the no-listener vs. listener comparison stays valid.

Approach

Per .claude/rules/benchmarks.md:

• Read-only operations use shared fixtures (already correct for 1K benches).
• Mutation operations that are idempotent (no state change when applied to already-settled state) now use shared fixtures for the 10K case.
• State-mutating operations that cannot be made idempotent use self-inverting call pairs (swap, alternating move targets, alternating reorder permutations) — each pair of iterations returns to the original state with identical cost in both directions.
• 1K benches retain fresh-per-iteration fixtures (setup overhead is acceptable at that scale).

[pkg-pr-new]

Open in StackBlitz

commit: d8fb727

[johnleider]

Review

Thanks for this — the diagnosis is correct and the approach is sound. I traced the source to confirm the idempotency claims, then ran both bench files before/after to measure the actual effect. The sortable half is solid; the nested half has one real defect: Collapse all (10,000) now measures an empty set instead of the operation.

✅ Verified correct

I confirmed in source that open / expandAll / select / selectAll and move / swap / reorder all run their full O(n)/O(depth) bodies with no early-return on settled state, so shared fixtures genuinely isolate operation cost. The onboard you removed was even bigger than the "~16ms" estimate — for the depth-4 tree it's ~48ms, which is what was dominating the 10K numbers.

Local before/after (illustrative, single machine):

createNested 10K	before	after
Expand all	48.6 ms	0.22 ms	✅ real O(n)
Select root cascade	48.5 ms	0.56 ms	✅
Select all	54.4 ms	1.63 ms	✅
Collapse all	46.6 ms	0.001 ms	❌ no-op (see below)

Sortable after-numbers are all sane (move 0.81–1.66ms, swap 2.07ms, reorder 3.32ms; no degenerate values). Two subtle things you got right and worth calling out: the self-inverting move/swap/reorder pattern keeps every iteration doing genuine work, and because move() only emits move:ticket on an actual index change, the alternating targets keep the emit path live — so the no-listener vs listener comparison stays valid. The listener is also correctly attached once. 👍

🔴 Collapse all (10,000) measures nothing

The fixture is tree10kCollapsed = createPopulatedNested(TREE_10K) — i.e. openedIds is empty. collapseAll() iterates [...openedIds], so on an empty set it spreads nothing, filters nothing, deletes nothing. It clocks ~0.001 ms (889K hz) — ~200× faster than expandAll on the same data and ~4,000× faster than the 1K collapseAll, which you (correctly) left on a fresh expanded fixture doing real work. The matrix will then show 10K-collapse as blazing and 1K-collapse as slow — the operation appearing to speed up as the tree grows, which is the misleading tier this PR is meant to remove, inverted.

The asymmetry: expandAll iterates children (structural map, ~11,111 entries regardless of open state) → idempotent with work → sharing an expanded fixture is correct. collapseAll iterates openedIds (variable, 0 when collapsed) → sharing a collapsed fixture zeroes the work. The PR description names this ("does nothing"), but for a benchmark "does nothing" = "measures nothing."

Fix: measure collapseAll on a populated set. Since it mutates to empty and can't be idempotent on one shared fixture, the cleanest option consistent with your own sortable approach is a self-inverting collapseAll↔expandAll alternation (both O(n), no setup cost). I've pushed that to the branch — see the follow-up commit.

Minor

• Open single node (10,000) on the expanded fixture measures the already-open fast path (Set.add of a present id skips the reactivity trigger). Microseconds either way for a single node, so the number isn't misleading — just noting the "open a node" intent never actually opens one. Low priority.

Out of scope, don't forget

• The tier badges won't move from this PR alone. They're driven by committed apps/docs/src/data/metrics.json + apps/docs/public/benchmarks.json, regenerated in standalone chore: regenerate benchmark and metrics data commits on a canonical runner. This PR is right not to commit a contributor's hardware numbers — but a maintainer needs to run pnpm metrics and land the follow-up for the badge fix to actually take effect.
• Commit type: .bench.ts isn't shipped and nothing in the package got faster, so perf(bench): will surface a spurious entry in the release notes. Suggest chore(bench): (or test(bench):).

Recommendation

One substantive change needed (Collapse all (10,000) against a populated tree — pushed) and a re-title to chore(bench):. Everything else is good to go.

[johnleider]

Thank you for your contribution and interest in improving Vuetify!