Closed joacub closed 1 year ago
Novice guess, but could you be repeatedly reading a lot of large files?
│ │ │ ├─ module @mui/x-data-grid-premium (@mui/x-data-grid-premium/node/index.js + 59) 4.4s (total 2s, self 1.3s) [read-resource 1.3s]
│ │ │ │ ├─ module @mui/x-data-grid-pro (@mui/x-data-grid-pro/node/index.js + 20) 3.1s (total 95 ms, self 440 ms) [read-resource 435 ms]
│ │ │ │ │ └─ module @mui/x-data-grid (@mui/x-data-grid/node/internals/index.js + 69) 1.4s (total 77 ms, self 1.7s) [read-resource 1.7s]
│ │ │ │ │ ├─ module reselect (reselect/lib/index.js + 1) 25 ms (self 45 ms) [read-resource 45 ms]
│ │ │ │ │ └─ module @mui/material (@mui/material/node/Checkbox/index.js + 5) 20 ms (self 124 ms) [read-resource 122 ms]
read-resource 1.3s
Novice guess, but could you be repeatedly reading a lot of large files?
│ │ │ ├─ module @mui/x-data-grid-premium (@mui/x-data-grid-premium/node/index.js + 59) 4.4s (total 2s, self 1.3s) [read-resource 1.3s] │ │ │ │ ├─ module @mui/x-data-grid-pro (@mui/x-data-grid-pro/node/index.js + 20) 3.1s (total 95 ms, self 440 ms) [read-resource 435 ms] │ │ │ │ │ └─ module @mui/x-data-grid (@mui/x-data-grid/node/internals/index.js + 69) 1.4s (total 77 ms, self 1.7s) [read-resource 1.7s] │ │ │ │ │ ├─ module reselect (reselect/lib/index.js + 1) 25 ms (self 45 ms) [read-resource 45 ms] │ │ │ │ │ └─ module @mui/material (@mui/material/node/Checkbox/index.js + 5) 20 ms (self 124 ms) [read-resource 122 ms]
read-resource 1.3s
Yes, but they shouldn’t be a problem in future compiling they should be cached.
I see one issue that was causing this bad performance, there where some cycling packages that was causing this going nuts, but again this is not an issue in the code is an issue in the compiler that becomes slow and slow in certain valid circumstances .
also this is in docker container and rust turbopack is not working pretty good there. There is a issue with https request than can be causing long timing also (don’t think is related)
What command are you running to generate this output? My app dir development is super slow atm. Every time I make a change it hard reloads.
What command are you running to generate this output? My app dir development is super slow atm. Every time I make a change it hard reloads.
Using this script
https://github.com/vercel/next.js/blob/canary/scripts/trace-to-tree.mjs
fyi https://github.com/vercel/next.js/blob/canary/scripts/trace-to-event-format.mjs converts trace to event format, can be loaded in chrome://tracing or devtools profiler.
Hey, do I have to run: node trace-to-tree.mjs?
For me, the last stable version is 13.2.4. Versions developed after that are very slow, taking even 15 seconds or more to refresh the page (MacBook M1 16GB).
@wh5938316 as always we'd love to investigate this further but would appreciate a reproduction so that it can be investigated.
@timneutkens https://github.com/wh5938316/next-slow
In my development environment, running next dev
for this example is very slow, with requests taking 25 seconds to respond. However, everything runs fine if the project is built beforehand.
If this example runs smoothly in your environment, I would like to know what else needs to be provided so that you can reproduce the issue.
My device: MacBook M1 16G
Hi, just want to bring this up a little bit (other issues about the same thing are relevant as well). I'm experiencing the same problem with mui, traces similar to the ones posted in this issue. The long times are usually spent when there is a file referencing many other files (like "@mui/x-data-grid-premium/node/index.js + 59"). This issue is not happening in the pages folder. Modularize imports doesn't help enough in this case.
In the provided example, the same page in the app directory takes at least 2x longer to compile than in the pages directory.
My device: MacBook M1 Max, 32GB
Yes, I am having similar experiences. I also think it's related to one of the material-ui packages. I am wondering if https://nextjs.org/blog/next-13-1#import-resolution-for-smaller-bundles could help with this? I just can't come up with a regex for material-ui or @mui/x-date-pickers
对我来说,最后一个稳定版本是 13.2.4。之后开发的版本非常慢,甚至需要 15 秒或更长时间才能刷新页面(MacBook M1 16GB)。
Yes, the speed of this version is normal, after that it will not work
对我来说,最后一个稳定版本是 13.2.4。之后开发的版本非常慢,甚至需要 15 秒或更长时间才能刷新页面(MacBook M1 16GB)。
Yes, the speed of this version is normal, after that it will not work
I can confirm that the speed is way faster on version 13.2.4 (useParams function is not existing though, not sure if it's related)
Without a reproduction, there isn't anything actionable we can do to help investigate this. Please open a new issue with proper system information and a complete, minimal reproduction, and we will investigate and try our best to solve this issue for you. Thank you!
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Verify canary release
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue
no response
To Reproduce
very slow compilatio for no that much modules some even are only one or two files an takes 5 seconds even more:
Describe the Bug
compile and load the first page
Expected Behavior
faster compilation
Which browser are you using? (if relevant)
no response
How are you deploying your application? (if relevant)
no response