search

vercel / next.js

The React Framework
https://nextjs.org
MIT License
124.34k stars 26.51k forks source link

Next 12 Build Performance on Windows #31021

Open lukaszfiszer opened 2 years ago

lukaszfiszer commented 2 years ago

What version of Next.js are you using?

12.0.2 and 12.0.3-canary.9

What version of Node.js are you using?

v14.15.4

What browser are you using?

Any

What operating system are you using?

Windows

How are you deploying your application?

N/A

Describe the Bug

Despite the announcement (https://nextjs.org/blog/next-12#faster-builds-and-fast-refresh-with-rust-compiler) the build time of Next12 app on Windows was not improved:

Upgrading to next@canary makes no difference.

Others have reported similar or even worse results: https://www.tpjnorton.com/blog/posts/next-js-12-performance-test-builds-appear-to-be-slower-not-faster

Expected Behavior

Faster build with next12 comparing to next11.

To Reproduce

In Windows Powershell run:

npx create-next-app@latest
cd app-name
Measure-Command  {npm run build}
Measure-Command  {npm run build}

Compare results with:

npx create-next-app@11
cd app-name
Measure-Command  {npm run build} 
Measure-Command  {npm run build}

Both build commands (with cold and hot cache) execution times are +/- the same.

jamsinclair commented 2 years ago

Seeing slower build times (30% increase) for a medium application after upgrading to Next 12.0.3 on Mac OS too.

Cold build times (with next build and type checking disabled)

Observed on CI too:

App

Would a build trace help provide more visibility? Happy to share privately with a maintainer.

amesas commented 2 years ago

Same here, 12.x is slower than 11.1

olaj commented 2 years ago

Same here, I'm on Windows. Builds are much slower, on multiple computers, and also tried in WSL, same result. Don't have time atm to dig deeper but well, just wanted to say i have the issue as well.

timneutkens commented 2 years ago

Please provide the .next/trace file both before/after and we'll have a look 👍 I'm thinking it might be related to outputFileTracing being a slowdown in the particular app or particularly on windows 🤔

olaj commented 2 years ago

@timneutkens My project is closed source and i can be a bit sloppy with secrets and stuff, are there anything secret in the trace files? Can i e-mail them somewhere? Or can i be 100 safe sharing them? 😨

I just ran now and the first build with Next 11 took about 36 sec, first build on Next 12 about 56 sec, second build took 10 sec on Next 11 and about 36 or something on Next 12. So its a major diffrence.

tbgse commented 2 years ago

We're also seeing much slower builds on 12.x, build time on vercel is up from 5 to 20 minutes, dev server is barely useable. Also happy to share files / code privately if that helps (created a support ticket on vercel too)

Edit: just found a solution (workaround?) by setting

module.exports = {
  experimental: {
    esmExternals: false,
  },
}

in next.config. This drastically improved performance. Without wanting to sidetrack the conversation, since this is true by default now, is there any way for us to find out why this setting impacted our performance so much?

timneutkens commented 2 years ago

@olaj there's no secrets/code in the trace file, only timings 👍

@tbgse happy to take a look at the app if that's available? Can you send the .next/trace as well?

tbgse commented 2 years ago

@timneutkens yeah happy to send through the files for builds both before & after. Since they're both pretty large, do you have a place where i can send them to?

timneutkens commented 2 years ago

Generally GitHub gist works for sending them, but any other way is fine too, feel free to email to Vercel support saying they're for me and I'll get them as well 👍

tbgse commented 2 years ago

Ok, just sent them through to Vercel support (case 00060994), thanks for looking into this! The app itself is private but if the logs get you curious I'd be happy to grant you access or walk you through it.

olaj commented 2 years ago

I've e-mailed as well now!

lukaszfiszer commented 2 years ago

@timneutkens I've uploaded build traces of empty application (generated using create-next-app) from WIndows to gist: https://gist.github.com/lukaszfiszer/9b3351645c2b7296c14c9266d4a5aa7c

timneutkens commented 2 years ago

@lukaszfiszer both of those traces are running Next.js 12.0.4 🤔

amesas commented 2 years ago

@lukaszfiszer both of those traces are running Next.js 12.0.4 🤔

12.0.3 had the same prob for sure. I have not done a real test, but I've the feeling that all 12.x releases has been slower.

sfiquet commented 2 years ago

@amesas The point is that he needs a version 11 trace and a version 12 trace to compare them.

jamsinclair commented 2 years ago

@timneutkens I have a gist of the Next 11 vs Next 12 traces if it's any help. Note: I've sanitised some of the module paths.

Thanks! 🙇

timneutkens commented 2 years ago

@jamsinclair @olaj for some reason output file tracing is slower than expected on your app, you can set outputFileTracing: false which disables tracing files during next build. I'd love to investigate these cases further but to do that we'll need access to the codebase, would that be possible for either of you?

jamsinclair commented 2 years ago

Thanks for the update! Yes, can confirm, setting outputFileTracing: false results in a much faster build with Next 12. Down from average 38 seconds to 28 seconds.

Edit: Unfortunately bit tricky for us to share our private codebase. Hopefully @olaj is able to privately share theirs 🤞

TheThirdRace commented 2 years ago

outputFileTracing: false

This also "solved" my problem. I'm on Window 10 too so you might have found the pattern.

The documentation on outputFileTracing: false make it sound scary to disable this, like the build could be missing files and not work... Should I be worried?

@timneutkens While my repo is private, I could send an invite for you to check it out if you still need examples of real repos. Furthermore, I'm in the midst of migrating from 11.1.2 to 12.0.7 so I could easily make 2 branches for testing purpose: nextjs-11-1-2 and nextjs-12-0-7.

Let me know if it's something that you're interested in validating.

Results of yarn build

11.1.2

Cold build: ~25s Warm build: ~14s

12.0.7

Cold build: ~35s (+10s average) Warm build: ~24s (+10s average)

12.0.7 + outputFileTracing: false

Cold build: ~19s (-6s average vs 11.1.2) Warm build: ~10s (-4s average vs 11.1.2)

olaj commented 2 years ago

Sorry, had missed the updated in here.

I see similar numbers, in one of my projects (with material-ui) it went from 36s to 14s or something like that. In my other project that haven't had that much issues with it went from 16s to 10s.

I could also invite you to a project if you like to!

github-actions[bot] commented 1 year ago

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the :+1: reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

TheThirdRace commented 1 year ago

Results with Canary

outputFileTracing cold build warm build
true 31.44s 18.40s
false 17.29s 8.37s

* cold build = no .next/ folder before build * warm build = .next/ folder exists before build

Needless to say, Windows still has problems with the outputFileTracing = true option...

TheThirdRace commented 7 months ago

According to a new message in NextJs 14.x:

image

🚨 Please DO NOT remove this option 🚨

This is still 100% necessary to disable it for Windows, even if everything is located within the WSL2. Removing that option makes my build take 2 to 3 times as long and my SSD is no slouch...

Unfortunately, this bug was raised more than 2 years ago and hasn't been solved... So if it's not getting fixed definitively for Windows, don't remove the option.