Build time regression in 2.10.1 #2856
Comments
|
I'm facing the same issue here : the build step for Nitro is now taking 2 minutes instead of the previous 40s :( Here is a CI job on the You can check the |
|
Investigating |
|
The same problem. The total time of the build process on Vercel increased to more than 6 minutes after the upgrade (Nuxt 3.14), from about 3:40 before. 
|
|
(please use 👍🏼 if you have same issue. please share a runnable reporuction if you can) |
|
Two observations inspecting (1) werewolves-assistant-web-next (
If anyone has relatively smaller projects (Nuxt or Nitro both fine) that slows down (in order of several seconds) only by upgrading Nitro to 2.10 please share it would be super helpful 🙏🏼 build 1 (extra prerender)build 2 (prerender)build 3 (production)(1) I used rollup built-in perf flag. If you want to locally do, it a little bit tricky you need to enable |
|
Here are the results from the ~150s project I have described, this time running without docker for my convenience, it is still 2x slower than previously: Nitro 2.10.3 - prerender phase of NuxtNitro 2.10.3 - build phase of NuxtNitro 2.9.7 - prerender phase of NuxtNitro 2.9.7 - build phase of NuxtNow, I could not replicate the fast results when downgrading. To my understanding, this means the reason lies within one of the dependencies, a dependency which is present in both 2.9.3 and 2.10.3, and is semver compatible between both versions. $ git reset --hard $HEAD
$ rm -rf node_modules pnpm-lock.yaml && pnpm add -D [email protected]
$ pnpm build # fast
$ rm -rf node_modules pnpm-lock.yaml && pnpm add -D [email protected]
$ pnpm build # slow
$ rm pnpm-lock.yaml && pnpm add -D [email protected]
$ pnpm build # slow, is it re-using some deps from node_modules?
$ rm -rf node_modules pnpm-lock.yaml && pnpm add -D [email protected]
$ pnpm build # fast again |
|
Playing with it a bit more: I have a project with |
|
Playing with a bit more, most of what I stated above is bullshit. Dependencies are hard. I was on this yesterday, yet somehow totally forgot by the morning. Turns out running actual debugger instead of guessing is very useful, too. Reproducible, to lesser degree but reproducible, on StackBlitz with hello-world. Probably degraded because of #2838 and then improved (for nuxt) by #2842, probably because nuxt passes ignored paths or something like that. Precisely, the regression is caused by moving the check on async resolveId(id, importer, resolveOpts) {
if (id === HELPER_ID) {
return id;
}
if (id[0] === "\0") {
return;
}
const withRawSpecifier = id.startsWith("raw:");
if (withRawSpecifier) {
id = id.slice(4);
}
+ if (!withRawSpecifier && !extensions.has(extname(id))) {
+ return;
+ }
const resolvedId = (await this.resolve(id, importer, resolveOpts))?.id;
if (!resolvedId || resolvedId.startsWith("\0")) {
return resolvedId;
}
if (!withRawSpecifier && !extensions.has(extname(resolvedId))) {
return;
}
return { id: "\0raw:" + resolvedId };
}, |
Aareksio
changed the title
|
Nice find dear @Aareksio. Any chance you could share your testing project btw? This amount of overhead for id resolution seems unusual. (your fix is good feel free to open a draft PR 🙏🏼 ) |
|
I am aware this is essentially reverting the PR and reinstalling the issue. However, resolving every single Not sure how to solve the issue properly without introducing the overhead :( |
8 tasks
|
Thanks for the investigation team. I will share the new build time when Nuxt will be updated with the new Nitro release. Stay tuned 😉 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
StackBlitz
vs
Reproduction
Describe the bug
The discrepancy, while small, is consistent with the minimal reproduction. In my project the total build time doubled from roughly 70-80 seconds to 140-160 seconds. Not sure what more of a reproduction exactly can I provide for this, luckily the change is noticeable even with minimal hello-world example straight from the home page.
One clue perhaps useful to the case, the nuxt prerender takes significantly longer; from ~10s to ~25s to do seemingly the same work; and it does not seem to be related to time spent on actual pages rendered:
Additional context
No response
Logs
No response
The text was updated successfully, but these errors were encountered: