Skip to content

perf: Reduce allocations in file hash computation#12102

Open
anthonyshew wants to merge 1 commit intomainfrom
shew/optimize-file-hashes
Open

perf: Reduce allocations in file hash computation#12102
anthonyshew wants to merge 1 commit intomainfrom
shew/optimize-file-hashes

Conversation

@anthonyshew
Copy link
Contributor

Summary

  • Deduplicate range-bound allocations in get_package_hashes — format strings for binary search bounds are computed once and reused for both ls_tree_hashes and status_entries lookups, eliminating 4 String + 4 RelativeUnixPathBuf allocations per call (440 total across 110 packages)
  • Use HashMap::entry API in calculate_file_hashes dedup loop to avoid cloning the HashKey on cache hits (the common case in monorepos where multiple tasks share a package)

Benchmark (quiet Linux sandbox, 80K-file monorepo, 25 runs)

Baseline Optimized Change
Wall time (mean) 749.9ms 734.1ms -2.1%
Wall time (min) 682.5ms 689.3ms within noise

These are allocation-level improvements — the effect is small on a benchmark dominated by filesystem I/O but the changes remove unnecessary work on the hot path of calculate_file_hashes (called for every task) and get_package_hashes (called for every package).

Deduplicate range-bound string allocations in get_package_hashes —
compute format!("{}/", prefix) and format!("{}0", prefix) once
instead of twice per call (once for ls_tree, once for status). Also
compare using str slices instead of constructing RelativeUnixPathBuf
wrappers for the range bounds.

Use HashMap::entry API in calculate_file_hashes dedup loop to avoid
cloning the HashKey on cache hits. Previously, the key was constructed,
looked up with get(), and on miss cloned again for insert + push. Now
the entry API does one lookup and only clones into unique_keys on miss.
@anthonyshew anthonyshew requested a review from a team as a code owner March 2, 2026 08:09
@anthonyshew anthonyshew requested review from tknickman and removed request for a team March 2, 2026 08:09
@vercel
Copy link
Contributor

vercel bot commented Mar 2, 2026

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

Project Deployment Actions Updated (UTC)
examples-basic-web Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
examples-designsystem-docs Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
examples-gatsby-web Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
examples-kitchensink-blog Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
examples-nonmonorepo Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
examples-svelte-web Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
examples-tailwind-web Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
examples-vite-web Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
turbo-site Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
turborepo-agents Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am
turborepo-test-coverage Building Building Preview, Comment, Open in v0 Mar 2, 2026 8:09am

@github-actions
Copy link
Contributor

github-actions bot commented Mar 2, 2026

Coverage Report

Metric Coverage
Lines 83.79%
Functions 79.70%
Branches 0.00%

View full report

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant