[turbopack] Improve regressed build speed on cross-compiled MUSL#91477
Merged
Conversation
mmastrac
changed the title
Contributor
Failing test suitesCommit: 2683091 | About building and testing Next.js
Expand output● segment cache (per-page dynamic stale time) › per-page value overrides global staleTimes.dynamic regardless of direction |
Merging this PR will not alter performance
Comparing 
Footnotes
|
Contributor
Stats from current PR🟢 1 improvement
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (25 files)Files with changes:
View diffsapp-page-exp..ntime.dev.jsfailed to diffapp-page-exp..time.prod.jsDiff too large to display app-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsDiff too large to display app-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsfailed to diffapp-page.runtime.dev.jsfailed to diffapp-page.runtime.prod.jsDiff too large to display app-route-ex..ntime.dev.jsDiff too large to display app-route-ex..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route.runtime.dev.jsDiff too large to display app-route.ru..time.prod.jsDiff too large to display pages-api-tu..ntime.dev.jsDiff too large to display pages-api-tu..time.prod.jsDiff too large to display pages-api.runtime.dev.jsDiff too large to display pages-api.ru..time.prod.jsDiff too large to display pages-turbo...ntime.dev.jsDiff too large to display pages-turbo...time.prod.jsDiff too large to display pages.runtime.dev.jsDiff too large to display pages.runtime.prod.jsDiff too large to display server.runtime.prod.jsDiff too large to display 📎 Tarball URL |
mmastrac
force-pushed
the
mmastrac/faster-link
branch
3 times, most recently
from
8db709c to
26eb2ce
Compare
mmastrac
force-pushed
the
mmastrac/faster-link
branch
3 times, most recently
from
3f56550 to
45e594c
Compare
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
bgw
reviewed
Mar 18, 2026
mmastrac
force-pushed
the
mmastrac/faster-link
branch
7 times, most recently
from
e01fca0 to
d685c45
Compare
- Refactor build_and_deploy.yml: replace per-target matrix entries with mmm-matrix declarative config, consolidate docker build script inline, pin actions to commit SHAs - Simplify .cargo/config.toml using cfg(true) (RFC 3695) to eliminate rustflag duplication across target sections - Remove GNU linker flags (rust-lld is now default on x86_64-linux-gnu) - Use rust-lld directly for musl targets, remove unused armv7 section - Add cargo xtask print-rustflags to replace .github/rustflags.yml - Release profile: thin LTO + codegen-units=64 for faster builds - Add --log-order stream to TURBO_ARGS for live build output - Remove mold linker integration from CI
mmastrac
force-pushed
the
mmastrac/faster-link
branch
from
d685c45 to
bee0063
Compare
bgw
approved these changes
Mar 20, 2026
Member
bgw
left a comment
bgw
left a comment
There was a problem hiding this comment.
This looks really good. Thank you for digging deep and fixing/documenting all of this cruft!
Comment on lines
+360
to
+361
| if [ "${{ matrix.os }}" != "windows" ]; then | ||
| strip -x packages/next-swc/native/next-swc.*.node |
Member
There was a problem hiding this comment.
Don't we still need to do something to strip the binary on windows?
We could do the stripping with a cargo option, we've just avoided it because we don't want to do the stripping on locally-built versions, and we only want to do it in CI.
Contributor
Author
There was a problem hiding this comment.
We don't currently strip on Windows so I left this status quo, but there's definitely some extra bytes in the release left on the floor here. I don't know if we have the right packages installed on the windows builders (strip and llvm-strip didn't work IIRC). I can try to pick this off in a follow-up.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
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.
What
Refactor build_and_deploy.yml to make it more maintainable, add documentation to all of the quirky flags we use and remove any flags that are not doing anything useful.
Non-goals
Why
After enabling LTO, our MUSL target builds got significantly slower. This wins back a good chunk of the performance that we lost by using cross-compilation to MUSL on docker images that are not slow as heck, while also trying to clean up this workflow that has accumulated some cruft over the years.
The timings are fairly unstable because of uncertain build machine variability, but I've tried to capture uncached runs where possible. I believe we can state that LTO has a slight increase in compile time, but MUSL builds are faster than the pre-LTO state of things.
Changes