-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vite is slow on large codebases on windows #4665
Comments
may same issue #4865 , try https://github.com/antfu/vite-plugin-optimize-persist |
no, it is not related; dependencies are loaded correctly, I just have around 600 files in project itself. |
This problem also exists if you're using a mounted remote file system. Since the speed of existSync(and other sync methods) is slow(due to latency), resolver was blocked, causing other (incoming) requests to wait for the previous (ongoing) resolve process to finish. The server degraded from (async) parallel processing to serial processing. The problem can be reproduced if you mount a NFS/CIFS partition from a remote server and run a project on that with Vite. |
@Yesterday17 PR welcome if you have a good setup to test and remove some of these |
I tried to make all |
Interesting, thanks for digging in. I hope we find a way to refactor it to async. |
import-meta-resolve might be a good async alternative of |
Finally I think I found the right issue. I have a similar problem, maybe it is the same, maybe not. The truth is that my development compile now takes about 30 minutes to compile, this is something that only happens to me in the team, the rest of my colleagues compile in 2 seconds having the same code base, only they are in Linux with Docker and I am in Windows without docker (I am not using WSL2), and no, it is not because of computer resources, and if it were I do not think the difference would be so brutal. We are working on a somewhat medium-sized project, about 400 components and counting. We are using Tailwind, and I have read that it can cause slow startup, but why only me if we have the same configuration? This is how long it takes my teammates. Does anyone have any suggestions, or at least where to start? |
I have the same problem. |
Check this @Thyiad #7608 (comment) |
We have been improving Vite's performance lately and I believe this has been fixed. Closing this as the work has been completed, but if there's more to work on, we'll track it at #12363 instead. Appreciate if anyone following would give Vite 4.3 beta a spin too. |
Describe the bug
While using Vite for bundling large codebase (around 700 files served) on Windows machine (reproducible both on windows 10 and 11 beta) Vite page load time takes around 5-30 seconds depending on drive type (NVME on-board SSD, NVME SSD, SATA SSD), comparing to <2 seconds on Mac (did not try on linux).
Core reason is
tryFsResolve
functionWhich is using accessSync call, which is internally using multiple sync FS calls, and NTFS (specifically NTFS, looks like FAT is working better) is rather complex system with multiple checks that can take milliseconds; also this is causing the server act in sync mode (instead of async) and not utilize the benefits of parallel http requests.
Another reason is rather slow HTTP service which takes several seconds overhead; I was able to win few seconds with page with this script (https://gist.github.com/Jabher/c9e5f9bb905c8ec2ab6289a181c2b6ce). Probably switching from express to fastify or native code will make things work faster.
Reproduction
issue seems obvious as long as performance result like was provided and specific code part was targeted as a reason of bug
System Info
Used Package Manager
npm
Logs
No response
Validations
The text was updated successfully, but these errors were encountered: