perf: Index Berry lockfile resolution overrides by dependency name

[vercel-gh-bot-5]

Summary

Berry (Yarn v2+) lockfile analysis previously performed a linear scan over every root resolutions override for every dependency edge, both while parsing the lockfile (populate_extensions visits every package × dependency) and again while computing per-workspace transitive closures (resolve_package / all_dependencies). On repos with many overrides this is O(edges × overrides): cal.com has 91 resolutions entries and a 113-package workspace, so the override scan dominated Berry resolution time.

This change groups the overrides once at lockfile construction into an FxHashMap<String, Vec<(Resolution, String)>> keyed by the unscoped name of the package each override targets, so each edge does a single hash lookup instead of scanning all overrides.

Correctness invariants preserved:

• Resolution::reduce_dependency returns None whenever the resolution's descriptor ident differs from the dependency's ident, so overrides targeting other names can never match — bucketing removes only never-matching candidates.

• Scoped/unscoped packages sharing a name land in the same bucket and are still disambiguated by the existing full-ident check inside reduce_dependency.

• Buckets are filled by iterating the previous ordered BTreeMap<Resolution, String>, preserving relative order, so first-match-wins semantics are unchanged.

• The map is Arc-shared so subgraph() (used by turbo prune) clones become refcount bumps; an is_empty guard keeps repos without resolutions on a trivial path.

• Author model: anthropic/claude-fable-5

• Reviewer model: openai/gpt-5.6-sol (gpt_performance_reviewer)

Hypothesis (declared before editing)

Replacing the per-edge linear override scan with a per-name index reduces the median wall time of turbo run build --dry=json --no-daemon on the pinned cal.com checkout by a nonzero amount with identical outputs, at the cost of one small extra hash map per lockfile.

Methodology

• Environment: Ubuntu 26.04 container, kernel 6.18.40, x86_64, Intel Xeon @ 2.90 GHz, 2 vCPU, 4283 MB RAM, low background load; rustc 1.97.0-nightly (e96c36b6f, repo toolchain nightly-2026-05-22); hyperfine 1.19.0; valgrind/callgrind 3.26.0.
• Corpus (cloned outside the checkout, detached at pinned revisions): calcom/cal.com @ 176037d0afbe572f870a3c702985e7cd83fe6c0c (yarn berry, 113 packages, 91 resolutions, 115 build tasks in the dry run) as the primary affected workload; t3-oss/create-t3-turbo @ 8f945b7bb3bfb3ca8358d48b1ff0214079bc11ee (pnpm) as an untouched-path check. (trigger.dev's pinned revision still uses turbo-1.x pipeline config and fails identically under both binaries, so it cannot serve as a timing workload.)
• Both binaries built with the identical command cargo build --profile release-turborepo -p turbo and preserved outside the checkout: baseline fba922b4… (50,459,232 B, from the clean checkout, verified bit-identical to a clean rebuild), candidate f282ff58… (50,462,240 B, +3,008 B).
• Timing harness: hyperfine, --warmup 3 --runs 10 per binary per block, both binaries inside one invocation, balanced AB/BA block ordering, warm caches with identical preparation, non-mutating dry-run command, daemon unused. Inference is block-aware: per-block median speedups, sign test, and a seeded 20k-resample percentile bootstrap over block speedups.

Evidence

End-to-end (cal.com, turbo run build --dry=json --no-daemon):

• Clean-checkout baseline phase: mean 148.2 ms ± 15.3 (20 runs). Post-edit after phase (identical command text): mean 125.8 ms ± 5.7 (20 runs).
• Final recorded comparison set (6 balanced AB/BA blocks, 60 samples per binary): block-median speedups [+6.61, +3.69, +4.13, −1.34, +6.93, +5.46]%; 5/6 positive; both orders improve on average; mean +4.25%, bootstrap 95% CI [+1.81%, +6.11%]. The one negative block contains visible transient load spikes in its candidate runs (129→168 ms outliers) and was retained per the predeclared no-removal rule.
• Cumulative across all 22 balanced blocks run this session (identical protocol/binaries/corpus): 21/22 positive; sign test p = 5.5e-6; AB mean +6.02%, BA mean +3.82%; bootstrap mean +4.92%, 95% CI [+3.88%, +5.97%]; pooled medians 133 ms → 125–126 ms (−5 to −8 ms per invocation).

Targeted mechanism benchmark (standalone harness outside the checkout; 5× BerryLockfile::new + transitive_closure per invocation on a pinned cal.com fixture; identical checksums 22825 from both builds; separate optimized builds with the diff stashed vs applied): 4/4 balanced AB/BA blocks positive, mean +17.23%, 95% CI [+16.09%, +18.05%] (40 samples per binary). Each invocation also carries ~35–40 ms of fixed untouched YAML-parse work, so the improvement on the changed code itself is larger.

Callgrind (deterministic instruction counts, one dry run per binary): total Ir 1,149,102,165 → 1,000,185,424 (−13.0%); Resolution::reduce_dependency 75.08 M → 0.18 M Ir (−99.8%); BerryLockfile::resolve_dependency 52.94 M → 1.69 M Ir (−96.8%).

Untouched pnpm path (create-t3-turbo): 4 balanced blocks, no statistically detectable difference (bootstrap 95% CI [−2.54%, +0.51%], spans zero) — consistent with the diff touching only berry/ code.

Correctness

• cargo test -p turborepo-lockfiles: 314/314 pass (includes berry override/patch/prune/subgraph/resolution tests).
• cargo clippy -p turborepo-lockfiles --all-targets -- -D warnings and cargo fmt --check: clean.
• cal.com and create-t3-turbo --dry=json outputs are byte-identical between baseline and candidate except the random run id (all 115 task hashes and globalCacheInputs identical).
• turbo prune @calcom/web (exercises subgraph() and pruned yarn.lock serialization): output directories byte-identical (diff -r clean).

Adversarial review

gpt_performance_reviewer (opposite model) reviewed the complete diff and evidence across four rounds. Earlier rounds requested stronger statistics (raw per-run data, more balanced blocks, block-aware CI), withdrawal of an unsupported scaling claim, and a targeted benchmark of the mechanism; all findings were resolved. Final verdict: approved, no blocking findings — "the replacement official timing set satisfies the stated acceptance criteria … a 95% CI wholly above zero ([+1.81%, +6.11%]) … the targeted benchmark and Callgrind diagnostics are directionally consistent with eliminating the per-edge override scan. The final claim is appropriately limited to cal.com rather than generalized to unaffected repositories."

Limitations / tradeoffs

• The measured wall-time claim is limited to the pinned cal.com workload (~4–5%, −5 to −8 ms per ~130 ms dry run on 2 vCPUs); CPU-time and instruction reductions are larger (−13% instructions). Repos without berry resolutions are unaffected; no timing claim is made for other repositories.
• +3,008 bytes binary size (+0.006%); one extra FxHashMap holding ~one entry per resolutions override per BerryLockfile, Arc-shared across subgraphs.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
examples-basic-web	Ready	Preview	Aug 20, 2026 5:32pm
examples-designsystem-docs	Ready	Preview	Aug 20, 2026 5:32pm
examples-gatsby-web	Ready	Preview	Aug 20, 2026 5:32pm
examples-kitchensink-blog	Ready	Preview	Aug 20, 2026 5:32pm
examples-nonmonorepo	Ready	Preview	Aug 20, 2026 5:32pm
examples-svelte-web	Ready	Preview	Aug 20, 2026 5:32pm
examples-tailwind-web	Ready	Preview	Aug 20, 2026 5:32pm
examples-vite-web	Ready	Preview	Aug 20, 2026 5:32pm
turbo-site	Ready	Preview	Aug 20, 2026 5:32pm
turborepo-factory	Ready	Preview	Aug 20, 2026 5:32pm