Usually high cpu usage is caused by the large number of files Meteor watches. This was improved in 1.11, but Meteor still watches too many files in node_modules. That should be fixed by removing these changes if someone wants to work on it (those changes should no longer be necessary due to some of the improvements in Meteor 1.11).
Meteor also watches more files than necessary for Meteor packages, but that will be a little more difficult to fix.
Regarding Meteor’s performance on Windows, there are two Windows specific things we can do:
On Linux/macOS, Meteor only writes the changed files during a rebuild instead of re-writing everything. On Windows, this optimization is still disabled for client only rebuilds. I finally understand well enough why it was disabled, so the next time I work on performance I plan to fix it.
We can change how some of the file operations are done to make them more efficient when Windows Defender is enabled.
Most other build performance issues are the same as on other operating systems, though they might be worse on Windows.
Gitlab CI/CD with my customized Ubuntu, but I tested also another and without significant differences. For building, Im using dedicated host (only for building, nothing else), new Xeon CPU and 256GB RAM and it takes about 30min. If I will run on host, it takes about 4min (7 times faster).
I tested on another host machines (e.g. with AMD comparable CPU, It takes little slower), and situation was the same, when I build outside and inside Docker container.
Host was always Ubuntu, Docker container also Ubuntu.
Years I was using Win10+WSL. In older Windows 10 releases with WSL2 was working great. With newer releases it was working slower and slower (but still accepted). But after migration to Windows 11, it was working muuuch slower, I tried everything to solve it, but without success. Therefore I had not another chance, I maked dualboot and run Meteor on Ubuntu. But it’s a shame.
Truth is, that reason of problem in my case could be also JetBrains Webstorm, because after few days of using, it consumed more that 20GB RAM! But still I don’t know the right reason, if problem was slower WSL, Docker, Webstorm or Meteor, or something else… Because non meteor projects (but smaller) with VSCode was running faster.
Few months before I switched to Mac and all the problems finished and Meteor works great …only building takes a long time.
I have only tried WSL2 on Windows 10, so I suppose take my recommendation with that in mind .
Yeah, I noticed that the default WSL setup takes up a lot of resources, memory in particular. Out of the box it “earmarks” a certain amount for the subsystem. What I had to do was make a configuration to make it less greedy. I was able to limit CPU and RAM that way.
I also disabled having WSL start on boot. That way if I just want to play a computer game or something, I am not paying the cost. When I open VSCode, WSL will start up. When I’m done, I have to manually shut it down, which is an inconvenience I’ve just gotten used to.
@moberegger …in my case was problem with the performance under WSL (always I mean WSL2) (limitation of WSL resources will lead to the even smaller performance). The problem is also, when IDE is running from Windows and working with files under WSL (it’s slow). I tried also install the fully KDE desktop and run JetBrains inside WSL, but it was not very stable and network desktop client was also not cheap.
From my migration to MacOS (I was not fun of Mac’s), but what is truth, I’m now mor productive, more focused to the work and less for the solving problems…
I strongly recommend you switch to running Meteor within WSL2 (Ubuntu 20.04) under Windows 10/Windows 11. This is my preferred Meteor dev environment.
Meteor builds much faster within WSL2 than under Windows. Also, the Windows version of VS Code has native support for editing files within the WSL2 Ubuntu environment.
I hope this comes sooner than later! I use Vue and meteor-desktop and both have really been limping along with a lack of support. I’d love to be able to update to Electron 18+ and Vue 3.
You can keep “SolidJS starter template” on the list of community items. I do plan to get to it eventually…
Regarding priorities: I feel like tree-shaking has been promised as “real soon now” for a couple of years. It would be great to see it finally see the light of day, at least as an option, so that I can finally decrease my bundle sizes without a ton of work. Meteor really sticks out here, as every other build tool I know of supports tree-shaking.
Another priority for me and SolidJS: SolidJS isn’t fully usable (specifically, dev mode is impossible to access, which makes debugging difficult) without support for NodeJS export conditions. See this feature request. I don’t think it should be hard to add support for export conditions when manually parsing package.json and simulating ESM, so it should be much easier than full ESM support.
For those who suffer with performance on Windows, try turning off your Windows Defender/Anti-Virus and try rebuild. It made a huge difference for us. Maybe I am imagining things… Let me know!
Stuck on Electron version 11.5.0 whilst it’s currently at version 20.1.0 officially with very regular new versions coming out. Cannot upgrade any further as it breaks
I just began to use Meteor as a side project, migrating (again) from another stack for always the same application.
The main problem I have is the compatibility with major libraries like vue3 (not supported) or discordjs (requires nodejs v16+). That’s a real concern that the framework didn’t manage to cope with libraries compatibility. I had to migrate to Svelte et Eris, but it’s a unsatisfactory workaround when you try to replace mainstream libraries.
Hello @a4xrbj1, I tried by your recommendation build it on another linux distributions, I tried also amazon linux and It not helped. Building duration is still long without change. Try In you case build outside the docker container and try the building time. I think, you will build it also multiple times faster. According to this problem I opened new discussion thread. Veeery long building time inside Docker container
I think you made a valid point: that looks like a multiple choice question. I for one develop in JS/TS and Python on a virtual Linux machine, and in Java on my main machine (which is Windows). All communication with the virtual machine.
All very valid points, and I feel you. Many moons ago, when I started with Node.js as a Windows user I encountered only frustrations. Meteor working well on Windows - which I agree should be the case - is only part of the solution. In my experience both Windows and MacOS are inferior if you are set to develop something remotely complex, especially if you need exotic tooling, additional services (e.g. databases), and so on.
Docker doesn’t always cut it. Plenty of low performance reports when used in Windows, and some issues still being reported with Mac OS.
I would suggest to create an actual Linux virtual machine using something like VMware, enable all available hardware virtualisation options in your BIOS, then snapshot it, and do whatever you like with it, run as many Docker containers your resources allow you, and so on. You communicate with it over virtual desktop, SSH, TCP/IP, any way you like. Share dev folders with your Win/Mac machine and use your preferred tooling from your environment, although you may want to check if your favourite tools like to communicate with folders mounted over network. But Meteor, Node.js, git, Docker - as a rule of thumb, all the CLI stuff needed for development - should run in your virtual machine.
I never, ever looked back at developing on Windows, with the exception of Java, just because IDE quirks and overall Java traditionally having great support on this platform.
P.S. I call BS in advance on anyone who will say running Docker inside a VM is wrong, performance will be worse. Show me a benchmark where Docker on a Linux VM is worse than Docker on a bare metal Windows machine. P.P.S. As an ex-Windows sysadmin, I promise that Linux is beautiful and easy to learn, reliable, and overall extremely satisfying.
Because non meteor projects (but smaller) with VSCode was running faster.
…only building takes a long time.
.