[EXPERIMENT — do not merge] Is the Turbopack FS build cache a net win? - #6078
Closed
waleedlatif1 wants to merge 4 commits into
Closed
[EXPERIMENT — do not merge] Is the Turbopack FS build cache a net win?#6078waleedlatif1 wants to merge 4 commits into
waleedlatif1 wants to merge 4 commits into
Conversation
Do not merge. Adds --force so Turbo cannot replay a cached log and reprint a stale compile time, which a .github-only commit would otherwise trigger.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Module graph byte-identical to run A; only the disk state differs.
NEXT_TURBOPACK_BUILD_CACHE '1' -> '0'. Module graph still byte-identical to runs A and B; the 12G on the sticky disk is now ignored by Turbopack. Records run B: warm was 2.2x SLOWER than cold and the cache grew 5.1G -> 12G.
2 tasks
Collaborator
Author
|
Experiment complete. Result, from three runs on this branch with a byte-identical module graph:
A warm cache made the identical build 3.2× slower, and the cache grew 5.1 GB → 12 GB across two runs of an unchanged tree — so a disk degrades the longer it lives, which explains the progressive slowdown observed up to 11.7 min. Acted on in #6080, which disables the cache and removes the mount. Closing — this branch was never for merging (it carries Two incidental findings, both now fixed separately: a 1 ms real-clock flake in |
waleedlatif1
added a commit
that referenced
this pull request
Jul 30, 2026
…uilds) (#6080) * perf(ci): disable the Turbopack persistent build cache It is a net loss at this app's size. A controlled A/B on one branch (#6078), three runs with a byte-identical module graph so only cache state varied: cache OFF 113s compile, 2m53s job cache ON, cold 162s compile, 3m54s job cache ON, warm 360s compile, 8m18s job The cache made the same build 3.2x slower. It also grew 5.1 GB -> 12 GB across two runs of an unchanged tree, which explains the progressive degradation seen on longer-lived disks (up to 11.7 min): the more a disk is written, the more the next run must read and revalidate. Flag manipulation is visible in the logs — the cache-on runs print `✓ turbopackFileSystemCacheForBuild`, the cache-off run omits it — and every run used `turbo --force` so none is a replayed log. #5869 enabled this on locally-measured numbers (105s cold -> 22s warm) that never reproduced in CI and are inverted here. #6072 then branch-scoped the disk to stop PRs restoring each other's caches; that fixed a real problem, but with the cache off the disk is unnecessary, so the mount, the pre/post size reporting, and the env gate all go with it. Pins `turbopackFileSystemCacheForBuild: false` explicitly rather than relying on the Next default: upstream already flips that default to true in canary/preview builds (vercel/next.js#94616), so leaning on the default would let a version bump silently re-enable this. Keeps ci-cache-cleanup.yml, re-scoped to draining the 5-12 GB volumes that PRs opened while the per-branch key was live still hold — nothing else reclaims them. It is a no-op for new PRs and can be deleted once drained. Caveat: n=1 per cell. The 3.2x effect size and agreement with ~15 prior observations make it convincing, but this is three runs, not a distribution. * docs(ci): correct the cleanup key comment after the mount was removed Greptile P2: the delete step still claimed its key must stay byte-identical to the Mount Next.js build cache step in test-build.yml, but this PR removes that mount. It is now a hard-coded legacy drain key that mirrors nothing.
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.
Draft, do not merge. Three measurements, then close. See
EXPERIMENT.md.NEXT_TURBOPACK_BUILD_CACHE=1was added in #5869 assuming a warm Turbopack cache speeds upnext build. Observational data from tonight suggests the ordering is cold < perfect-warm < mismatched-warm — i.e. the cache may be costing wall time.Those observations each varied commit and cache state. This branch holds the tree constant: every commit touches only
.github/**+EXPERIMENT.md, so the Next module graph is byte-identical across all three runs and only cache state changes.NEXT_TURBOPACK_BUILD_CACHE'1''1''0'Two traps this defuses, both of which already produced wrong numbers once:
.github-only commit leaves Turbo's task inputs unchanged, so Turbo would replay a cached log and reprint a stale compile time, fabricating the measurement.--forceprevents it. Five phantom runs had to be discarded from the observational data for exactly this.cancel-in-progressmeans pushing early cancels a run, and a cancelled run still commits its partial cache. This is why an earlier conclusion ("a brand-new sticky key is not cold") was wrong: the "first" run had a cancelled sibling 3 minutes prior that had already written 5.1 GB. Each run here must reachcompletedbefore the next push.Measurable only because #6072 added the pre/post
dureporting.