Meteor for windows is very-very slow

[JWo1F]

_2 Upvotes_ Hi all! Meteor for Windows is very-very slow. When I make a change I should wait for 20-30 seconds while a page reloading..

[gdoteof]

+1.. this is insufferable on windows.

Same issue on brand-new project and extremely small / new project.

Build time is ~30seconds on making a change to jsx file. Maybe it's worth noting that running meteor --version or meteor help both take several seconds to return.

Meteor version: Meteor 1.3.2.4

Windows version. Windows 10 Home.

~2500 files in node_modules

no public directory for this testing

[abernix]

If you are here to +1 this issue...

...please also include:

• Your version of Meteor
• Your version of Windows
• If it happens on a brand-new project, existing project, or both. (Please at least try a brand-new project)
• Number of files/directories in your node_modules directory and public directories (Right-Click > Properties)

Known problems (from the Unix side of things)

• Huge dependency trees of node_modules.
• Large numbers of files (10k+) in public.

These issues are being tracked separately but will likely also affect Windows users.

[aedm]

46 seconds rebuild time here.

• Windows 10 Pro, Athlon II 4-core CPU @2.6Ghz, 8G ram, SSD.
• Meteor 1.3.2.4
• Project is 3 months old, was created anew (not a fork)
• node_modules: 9 folders (meteor-node-stubs, moment, react, react-addons-css-transition-group, react-addons-pure-render-mixin, react-date-picker, react-dom, react-markdown, react-mounter)
• 4 local packages in packages/ folder (they almost never change)
• public/ folder only contains 5 small image files
• source is ~50 js/jsx files (not including packages), ~90 scss (including Bootstrap4)

After METER_DEBUG=1, this is what I get when I change a single js file:

| Top leaves:
| Babel.compile...........................................13,197 ms (102)
| files.lstat.............................................10,106 ms (10608)
| files.writeFile..........................................3,664 ms (148)
| other compileUnibuild (the app)..........................3,386 ms (2)
| files.stat...............................................2,426 ms (6193)
| files.readFile...........................................1,789 ms (666)
| files.readdir............................................1,504 ms (1288)
| composing source maps....................................1,373 ms (1)
| getPrelinkedFiles toStringWithSourceMap..................1,364 ms (1)
| CssTools.parseCss........................................1,034 ms (13)
| other ImportScanner#_tryToResolveImportedPath..............931 ms (1427)
| linker File#getPrelinkedOutput.............................767 ms (44)
| files.realpath.............................................609 ms (203)
| other PackageSourceBatch.computeJsOutputFilesMap...........571 ms (1)
| files.rm_recursive.........................................464 ms (2)
| ImportScanner#_getInstallPath..............................456 ms (655)
| other ClientTarget#write...................................408 ms (1)
| sha1.......................................................359 ms (1199)
| files.rename...............................................343 ms (150)
| CssTools.stringifyCss......................................318 ms (1)
| other Target#_runCompilerPlugins...........................288 ms (1)
| other plugin ecmascript....................................226 ms (1)
| ImportScanner#_findImportedModuleIdentifiers...............206 ms (527)
| other PackageSourceBatch#_linkJS...........................110 ms (77)
| Isopack#getUnibuildAtArch..................................108 ms (1910)
|
| (#4) Total: 46,742 ms (Rebuild App)

[joannesalfa]

I think it's related to "dependencies" from some apps may f@ck your packages up, in that case I ran my project which added session package and then downgrades to version 1.1.10 (new one was 1.3.2_4) it seems very odd!

http://i.imgur.com/8MyU2AB.png

And caused to slowdown.

I believe I managed to fix this issue. Updating was less than 5 seconds. Reply me if someone has still issue.

[lorenzogm]

Hi @joannesalfa

How did you fixed it?

[joannesalfa]

@lorenzogm

There are kind of ways to fix it:

1) Uninstall, make sure to delete existing packages in .meteor folder in %appdata% and Reinstall Meteor.js (to keep default and recent packages, not downgraded packages, not sure which are ones)

2) After of reinstalling, create new project and run, if is faster than before, you should keep package.json to control the dependencies; without package.json, they would find oldest packages to f@ck your recent packages up.

If it doesn't run faster, is possible you have still old packages in .meteor folder.

[Herb-sh]

My last build was at this very moment and it took exactly 10 minutes to finish. The simplest mistake and it will take the same amount of time to rebuild, same thing happens with refresh. Basic example seem to work fine, Node modules seem to impact a bit but it is not clear.

1.) Windows 7 2.) Latest meteor(1.3.2.4), 3.) Autoprefixer and Faker inside node_modules folder (2 packages) 4.) 1 month old project 5.) Approximately 40 meteor packages

I have spent hours just waiting like a tree, not accomplishing anything. I see so many developers with different OSs having the same problem.

It should be some way to prevent this time consuming process

[gdoteof]

@Herb-sh I know this isn't a 'real' solution; but I have not had these problems on Linux.

On my windows machine, which I don't use so often, I was able to get the new "ubuntu bash on windows" feature; and then I was able to run linux native meteor which was much faster.

I would cry if I were doing active development on a real project in meteor on windows, I hope for your sanity you find a solution.

[Herb-sh]

Thank you @gdoteof i will give it try, i can not see what i have to lose at this moment :D. Thanks!

[heberallred]

@gdoteof If that bash shell in Windows works, that will be awesome! I will give it a try. I would love to work in Windows, and still have access to faster Meteor. Thank you for the post. I had not heard of this before.

[ilan-schemoul]

sill ~20 seconds for compiling on Windows :| let's hope that ubuntu shell on redstone will fix that. If anyone have the insider build and can tell a word about that maybe ?

[heberallred]

After testing with the Linux Bash Shell for Windows 10, I honestly think this is one of the best things Microsoft has done in a long while (at least of the features I will use). Linux for Windows! (and it's not just a Virtual Machine)

It's currently a little buggy, particularly in the networking, but Meteor restarts are MUCH faster, and it feels good having Meteor running in it's more "native" environment of Linux. Network access within the shell seems to be a little slow (such as using apt-get to install npm, nodejs, etc.), but actual processing/running if my Meteor app is very good. I think this is addition to Windows is of significant importance, and I hope they work out the bugs ASAP.

Depending on your situation, it may be worth waiting until the final release (unless you're willing to deal with glitches, etc.). Currently, the only way to get it is to be on the latest Insider Preview Build of Windows: http://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/

[magbeat]

@heberallred have you found a way to connect to a running MongoDB on the "Windows host"? Localhost with port does not seem to work.

[ilan-schemoul]

@heberallred thanks a lot for these informations. I'm so glad of Linux in Windows. That's really cool :D

[heberallred]

@magbeat I haven't tried to connect to MongoDB on the Windows Host from within the Bash Shell. Up to this point, I have only used the built in MongoDB that comes with Meteor. On a side note, when Meteor is running in the Bash Shell, I am able to connect to it from Windows at the normal address http://localhost:3000

[heberallred]

@magbeat Using RoboMongo in Windows I am able to connect to Meteor's MongoDB in Bash Shell on port 3001.

[rapito]

I have to say that I have given up on this issue and moved on from meteor. I know this may require lots of work and tinkering to solve, but it isn't just 2 or 3 devs with this issue, must of windows users are suffering from this. And dont get me wrong, I understand how hard it is to support a multiplatform framework such as meteor. But I can't help to feel that windows users are being kind of ignored or not getting proper feedback on this. A "we are working on it, hang tight" would keep my hopes up, but nope.

I've been using meteor since its really early days, and it saddens me to let it go. But we need to be productive as well.

[joannesalfa]

Like I said if you have old packages can cause slowdown on your windows, Meteor.js for windows does not have a proper failsafe.

[joannesalfa]

Here is my gif of initial meteor.js (like less than 1 min) and update meteor (average 10 seconds)

[gdoteof]

@rapito I strongly recommend looking into the 'bash on windows' solution. If you aren't familiar with the *nix console it relatively straight forward (and approximately infinitely better than cmd.exe anyway) but it does make meteor usable.

Currently the bash on windows is only available in developer builds which microsoft makes a bit of a pain to get, but they are supposed to go to everyone I believe this summer.

It is good enough that I would not be surprised if meteor et. al. drop windows support entirely in the next couple years and just require users to go the linux route.

[dngeldark]

very slow in a Windows 7, first time installing, fresh install. Hello linux, hello old laptop we meet again.

[rafialikhan]

Stuck on ''Starting your app'' - on a fresh project.

Windows 7 Downloaded Meteor Windows Installer (https://s3.amazonaws.com/meteor-windows/InstallMeteor.exe) Gets stuck in Staring your app. Then updated meteor 1.3.4.4 (meteor update) Continues to gets stuck in Staring your app.

Some other threads mention MongoDb related errors, trying to resolve that. Will post back if that resolves it.

Also +1 on time to refresh after making small changes - anywhere between 20 - 60 seconds. This one reason will kill meteor for windows developers and even mac/linux users have not been spared. :(

Update: posted a solution here https://forums.meteor.com/t/meteor-stuck-at-starting-your-app/25592/7

[turbobuilt]

Reloads on windows 7 were terrible for me - I have a VM and reloads are quick now. However, the VM itself has performance overhead, so I'm downloading windows 10 so I can get bash + windows combined! Hopefully this works.

Meteor advertises itself as a solution for quick development. Honestly, I think meteor ought to NOT even have a windows version because the current one is so slow to develop with that it gives users a bad taste of the framework. I understand that it is not the developers' fault that windows doesn't have the same features linux does - but I say either fix it on windows or drop support. As soon as anniversary edition windows with bash comes out and is confirmed working, get everybody on that.

[ilan-schemoul]

Totally agree with @dtruel

[ThomsCass]

+1

[ilan-schemoul]

@heberallred can you share me how you did to make shell to work with meteor ? (#7583)

[turbobuilt]

Windows 10 anniversary edition is out! I downloaded it the first time, and enabling the subsytem for linux caused my system to crash... But i did a system refresh and retried, and it's working great now! Each refresh takes about 3 seconds and this is on real Windows 10, no VM!

[rwuttke]

The Windows 10 anniversary edition + Ubuntu Bash works nicely, though If you want to test meteor out on a remote client, you will need to add the port into the Windows Firewall, with an Inbound Rule for port 3000.

If you don't do this, this will work

http://localhost:3000

but, this will not

http://192.168.1.101:3000

Well that was my experience anyway.

[linvi]

@dtruel How slow was it before the update and how old is your project?

[AirBorne04]

UPDATE: my on access scan did not do any bad on performance UPDATE2: maybe it helps somebody searching for similar issue i realized i had nested node_modules folder in my pre 1.4 app and after the new npm flattens those folders, but the original nested node_modules where still there but not needed any longer, that saves my roughly 7 seconds on rebuild.

I have issues on windows too. The "Top Leaves" from the meteor profiling are files.lstat, files.rename, files.readFile, files.stat, files.readdir with 17s out of 24s overall. In my quick not too professionally done tests it showed that this functions do perform much better on linux than on windows. Interestingly also the sync vs non-blocking perform better which could be fine for build tasks (~20 to 30% in my tests just a thought). Since the latest updates of meteor also looking into the node_modules it might enforce this issue. Any confirming rejecting thoughts on this?

[Sandeep3005]

meteor create simple-todos

I am waiting for 4 hours for this command. Meteor version is 1.4 Is there any solution ? Will this be same on machine ?

[linvi]

@rwuttke didn't you face any problem with MongoDB on Windows 10 anniversary and Bash? I could not find any way to have meteor successfully run start it.

[rwuttke]

@linvi Using the internal MongoDB, I have had no problems, created a new app, opened port 3000 in the windows firewall, used meteor npm to get the packages and then meteor as usual.

All ran smoothly.

[AirBorne04]

I think one of the issues might be that the build system is checking the whole node_modules folder for diffing when performing a build and this is a lot of files. I think it was much faster before npm got integrated into meteor and it might be possible to optimize the way meteor is diffing those files on windows because i see that taking up quite a high amount of time doing lstat.

[CTimmerman]

https://www.exratione.com/2014/09/nodejs-is-too-inefficient-to-monitor-files-so-use-bash-scripts-instead/ says Node.js sucks at finding files newer than a timestamp and recommends using a separate tool: Bash: find ${MONITOR[*]} -type f -newer ${TIMESTAMP_FILE} CMD: forfiles /P <dir> /S /D +12/07/2013 PowerShell: get-childitem -recurse | where-object {$_.lastwritetime -gt "12/07/2013"}

[mizzao]

@dtruel are you still using Meteor on WSL? And if so, are you placing your project in the Linux or Windows (/mnt/c) filesystem, and are you editing your files through the console or through an IDE on Windows?

[turbobuilt]

@mizzao I put linux on my machine and am using that! Works great! When I was using meteor on WSL, it had acceptable performance. However, the upgrade to 1.4 didn't work for me and for others: https://github.com/meteor/meteor/issues/7583 . That was the reason I just installed linux. I'm glad I did though, because it works fastest there.

I had my files in my Documents folder, but that was mapped to /mnt/c/Users/me/Documents in linux

[andrei-markeev]

I had terrible problems with performance on Windows (as stated above in this thread), but then I moved to the latest 1.4.2 and it became much better, especially with hot code reload.

Moving to the latest version was somewhat drastic (you probably don't want to do it exactly like I did) - I had issues with automatic update process, so I decided to reinstall it fully, by doing the following:

1. I removed the meteor folder from Roaming
2. Removed meteor from Programs and features
3. Installed meteor from scratch
4. Created empty folder and initialized the project there with meteor create
5. Removed all content from newly created folder and copied my project files there (except of the .meteor folder)
6. Installed again all the packages that my project was using with meteor add <...> and removed packages that my project was not using.
7. Also had to run this silly npm install babel-runtime of course (even though I don't use babel :rage:), it doesn't start without that thing in 1.4+
8. And finally boom - it works

Even after doing all this on Windows it's still slower than on Linux, but somewhat acceptable at least.

Also I think reinstalling meteor is actually not necessary, and same should be possible to achieve with following steps:

1. meteor reset (warning: you loose all data from local db)
2. meteor update to latest version and then meteor upgrade and meteor upgrade --all-packages
3. do first two steps for all of your projects before continuing further
4. remove meteor folder from Roaming - after that meteor downloads all necessary packages and meteor-tool again (which is slow), but at least all the old versions of packages and old versions of meteor-tool are cleaned out

Some more tips:

1. meteor reset from time to time really helps
2. try to put most of your stuff inside server and client folders, if most of the code is common, Meteor handles this much worse during hot code reload
3. initial startup time is still slow, even on Linux it's about 30 seconds for my particular project, and the project is to be honest quite small.. MDG is working on that according to the project roadmap, hopefully something changes there.
4. amount of files in node_modules seems to be affecting performance as well, so try to choose npm modules that don't have huge dependency trees

Personal note: following these tips makes using Meteor quite inconvenient. And not following them makes development process slow... :disappointed: :disappointed: :disappointed:

[shiwamavg]

I am running angular2-meteor, the application is really slow, it hangs my local server while development. mongodb is also very slow in fetching data to the client.

[x5engine]

32GB of RAM and i7 6700K and it's slow as a hell and a small tiny server with 1.5GB of RAM can run this in 2 seconds

[x5engine]

@stubailo now it's a fucking half an hour it's running and trying to build the app!! what's going on ?

want to reproduce this? clone Telescope then run it in a windows 10 64bit and watch it go crazy!!!!!!!!!

[turbobuilt]

@meteorplus there is no hope for meteor on windows, at least right now. The best solution is to dual boot linux - I made the switch and am very glad I did. You can also use the windows subsystem for linux which is almost as good. It's like linux natively on windows. To enable it and start using, see here: https://msdn.microsoft.com/en-us/commandline/wsl/install_guide

There is a caveat though - I couldn't get meteor 1.4 to work, only 1.3 on Windows subsystem for linux. So I suggest just dual booting linux, or actually since you have such a powerful machine, using a VM

[x5engine]

@dtruel I do not need to dual boot I have a premuim account on c9.io and have many workspace running a linux Os on a dedicated server

and trust me there meteor runs like in seconds!!!

but come on do something with windows!

I found the issue comes when you add or remove a package then it tries to rebuild the app but fails in a loop trying to download packages or something.. but the first build is not that long may be 1mn that's all!

[neilharia7]

It's taking forever even to install meteor on windows 10

[AirBorne04]

After updating to 1.4.3.1 the super slow css build for me went away and i have rebuild times under 5 seconds, which is still not nothing but much better than min 20.

[hwillson]

Hi all - there have been several Meteor releases since this issue was created, and numerous performance updates made to the build tool. As such, I'll close this issue for now. If anyone notices slow rebuild times using Windows with a recent version of Meteor (1.5 as of this post), please create a new issue with the performance issue details (see Reporting a bug in Meteor). Thanks!

[brettg2]

I'm sorry but this is literally the reason people are leaving Meteor. It consistently takes at least 10-20 minutes downloading, extracting etc. This is a joke!

[gdoteof]

Is it? I would think that the population of meteor users who are using windows exclusively is actually quite a small %; especially when it's so easy to use the built in ubuntu now which allows you to use the linux version

[aedm]

Please note that Windows Defender can slow things down quite a bit for Meteor, especially updates. I usually turn it off completely when working with Meteor, since it scans every generated JavaScript file for malware (as far as I can tell).

[brettg2]

@gdoteof

I would think that the population of meteor users who are using windows exclusively is actually quite a small %

And I wouldn't be surprised if that % gets smaller. The more MDG ignores this issue and the functionality of the meteor-tool in Windows, the more people will move to other platforms that have better compatibility.

it's so easy to use the built in ubuntu now which allows you to use the linux version

So the answer to this problem is to run it in Linux?