Meteor: 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..

[stubailo]

Please provide a full reproduction as described in: https://github.com/meteor/meteor/wiki/Contributing-to-Meteor#reporting-a-bug-in-meteor Without a way to replicate your problem, we can't debug and fix it.

[JWo1F]

Way to replicate my problem:

1. download meteor from here: https://install.meteor.com/windows
2. install meteor
3. run cmd
4. type: meteor create test
5. type: cd test && meteor
6. change one file in this dir
7. waiting from 20 to 30 seconds while page is reloading..

[stubailo]

OK, we'll look into this! Thanks for the reproduction recipe, it's good to know that you are encountering this issue with a newly created app.

[JWo1F]

For example. The same issue in all popular browsers.

[stubailo]

What Windows version are you running?

[JWo1F]

Windows 10 x64 just now, but I had the same issue in windows 8.1

In linux (Ubuntu 15.04 x64 and ArchLinux x64 + KDE) all working perfectly.

[Slava]

Note that the screenshot is featuring a browser that we don't normally test (Yandex Browser). It is supposed to be the same as Google Chrome, but it could be an issue specific to Y.Browser too.

[stubailo]

@JWo1F did say "The same issue in all popular browsers." Hopefully that includes browsers that aren't from Yandex.

[JWo1F]

Yea, @stubailo are right. I have the same issue in Chrome and Firefox (and IE / Edge).

If you need more technical data about this issue, I'll give them.

[4thlaurocruz]

this is a meteor issue, it downloading sources one at a time in debug mode. to fix this add a --production flag

[JWo1F]

@4thlaurocruz in production mode I can't see a full debug information about my files because they will be merged into a single file. It's a bad idea.

[bjconlan]

Yeah, I too am having this issue on meteor 1.2.0.1 using windows 10 (32 bit).
Looks like on every js(x) code change the server is verifying the state of the project by doing the entire restart flow.

Selecting package versions
Downloading ... 
Building...
Meteor server restarted

While modifying just the html seems to just show a => Client modified -- refreshing (xX)
(while also being very slow)

[4thlaurocruz]

yes and the git version of meteor, minification isnt working at all.

[4thlaurocruz]

linux has this issue as well

[stubailo]

You need to add the package standard-minifiers to get minification, @4thlaurocruz. If you are running from installed Meteor, you get this automatically when upgrading, but not from the checkout.

Please read the notes here: https://github.com/meteor/meteor/wiki/Breaking-changes-in-Meteor-1.2

[4thlaurocruz]

try opening the chrome properties and disable cache. each refresh takes at least 30 to 40 seconds to complete

[stubailo]

@4thlaurocruz what are you talking about when you mean "refresh"? And is this in production or development?

[4thlaurocruz]

this for development, refresh in chrome browser with cache off.

standard minifiers also removed.

in the git master version, js is minified even no --production flag

and meteor only uses one core 100% other cores are not used.

On Fri, Sep 25, 2015 at 12:20 AM, Sashko Stubailo [email protected]
wrote:

@4thlaurocruz https://github.com/4thlaurocruz what are you talking
about when you mean "refresh"? And is this in production or development?

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5091#issuecomment-142977372.

[4thlaurocruz]

and i also seen that when have multiple meteor application with different ports, the first one will be minified, but the rest wont have a one minified js file like the first.

[stubailo]

You should add the standard-minifiers package, maybe that will help?

[4thlaurocruz]

css is okay here, my problem is javascript, it is downloaded one at a time.
and it really took ages.

On Tue, Sep 29, 2015 at 8:35 AM, Sashko Stubailo [email protected]
wrote:

You should add the standard-minifiers package, maybe that will help?

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5091#issuecomment-143910902.

[stubailo]

Since you are developing locally, the network speed between your browser and your local web server should be pretty much instant. I don't see how the network speed could be the issue.

[4thlaurocruz]

im developing remote from google cloud that is why this is a blocker

On Wed, Sep 30, 2015 at 12:42 AM, Sashko Stubailo [email protected]
wrote:

Since you are developing locally, the network speed between your browser
and your local web server should be pretty much instant. I don't see how
the network speed could be the issue.

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5091#issuecomment-144114823.

[4thlaurocruz]

this is fixed on top of nginx. but when using meteor binary alone,
downloading javascript is a blocker.

On Wed, Sep 30, 2015 at 1:09 PM, Lauro Cruz lauro.[email protected]
wrote:

im developing remote from google cloud that is why this is a blocker

On Wed, Sep 30, 2015 at 12:42 AM, Sashko Stubailo <
[email protected]> wrote:

Since you are developing locally, the network speed between your browser
and your local web server should be pretty much instant. I don't see how
the network speed could be the issue.

—
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5091#issuecomment-144114823.

[Ice32]

Is this problem being worked on? Same thing happens to me...Meteor on Windows 10 takes 15 seconds to reload simplest app possible after changing the file, while on Ubuntu it works like it should. I'm using the latest Meteor version.

[rwuttke]

I am having the same problem on Meteor 1.2.1 it is an extremely long wait from clicking save on a file, waiting for the rebuild, waiting for the websocket, then waiting for it to refresh to the page, yes there is a long time with a blank page in between.

Even changing between routes manually takes a long time.

This used to be smooth as.

[isdzulqor]

Having the same problem, Meteor Js run slowly in my Windows 10, Hopefully it will fixed as soon as possible

[shadowzick]

I'm having this same problem, I'm hoping that it will be fixed very soon.

[SamDeacon]

Same problem here the rebuild is rediculous.
windows 8.1
basic app with no packages takes 20 - 60s

(I would use on cloud9 like everything else i do but meteor/mongodb exceeds the workspace ram capacity and the build gets killed)

[rapito]

Same thing happens to me on W10 64bits. Simplest app takes forever to reload, after any server or client side file changes.

This used to be instantly on older version of meteor.

[gcacars]

Same here

[weekaah]

Same here Windows 10 x64. Refreshing takes 10-20sec, even when editing starter meteor app.

[greg-ashby]

Thought it was just me. Guess not :) Windows 10 as well.

[SamDeacon]

Cloud9 now has enough ram on free tier to run meteor without killing the build/serve process

Runs ubuntu... The changes aren't instantaneous like they are on the mac YouTube videos... 5-10 seconds but much less painful than 30-60 seconds locally....

[heberallred]

It would be sooooo nice if Windows Meteor restarted as fast as on Linux. Honestly, I bought a Mac for that 1 reason alone (faster restart on Meteor), and use it strictly for Meteor coding. I would prefer to code in Windows since that's where I have all my other software tools. Restart time taking 20 or 30 seconds per code change change adds up fast. My Mac restarts probably 3 times as fast on code changes, likely because it's Unix based and more native for NodeJS/Meteor.

[JoeKnow]

It would be nice if this was faster.. Engineers like efficiency. This is sufficiently deficient.

[TWKDreamState]

+1 :(

[JayLawler]

me too....

[gcacars]

My tip: don't use Meteor installer for windows. Install meteor from https://github.com/meteor/meteor/wiki/Meteor-on-Windows:-Alternate-installation. It works very fine.

[MichaelJCole]

It's not just Windows. Meteor is slow on Linux too. I have a 500mb/s SSD, and my "builds" are 30 seconds. 10s of that is sqlite. #4284 has some more info.

[slaphead]

I am experiencing the same thing here. Using webstorm or starting from command line does not make a difference. It's meteor 1.2.1 with velocity using jasmine for testing. The client side changes and refresh can sometimes take 5 minutes?! Even if I stop the app and start it again.

Closing the browser tab and opening a new one also does not help. Lastly, I am using Windows 10 x64, Firefox and Chrome. Please let me know if you need any further information

[andrei-markeev]

Same for me, unfortunately. Tried Windows 7 and Windows 10. Very slow build. Meteor 1.3.0, 1.3.1. More like a turtle than meteor :( On Linux Debian - works great.

[Rahman-S-M]

I'm also experiencing very slow startup and refresh in windows 7. Any way we can tweak this to increase the speed in windows?

[Rahman-S-M]

How meteor updates the changes? Is there anyway we can change the default behavior and specify which set of files to look for changes?

[TWKDreamState]

I don't know if this will help anyone but I was suffering excruciating refresh times and build times. I found a post somewhere talking about the files in the public directory and that Meteor indexes them.

At that point, I was just using it as a holding place and didn't really give much thought to it. I had hundreds of images from a previous website, a whole ton of bower plugins - most of which I wasn't using (I am loading what I need using ocLazyLoad), css files, test html, etc. I didn't think it would factor into the speed as I was only calling what I needed when I needed it.

After reading the post I decided to clean up my public directory and only have what was actually being used by the app. I also cleaned up the npm-modules directory. I get a 2-3 second refresh now (as opposed to 40-50 seconds) and the build time is a great deal better. Might be worth a check?

[ittechsathish]

I am also suffer from this slow build performance issue in windows 10, using 1.3 meteor version.
difficult to digest the wait duration, for a change to appear in the browser.

Do we really have solution for this?

[poojabhimte16]

does meteor works on windows same as mac nd other os ?. I installed meteor on windows and i run 'meteor' using cmd then i created a new app 'explore' using 'meteor create explore', after that i again run 'meteor' command using cmd then it should show following things: started proxy, started mongodb, started app
but it shows only 'started proxy' and 'starting your application' and its showing for long time
i do not know what is the mistake.. plss help me out in this

[baloodevil]

For troubleshooting build times, from command line enter set METEOR_PROFILE=200. Then when building with meteor, the console will log any operation that takes longer than 200 milliseconds.

[poojabhimte16]

@baloodevil , it is still the same, idle at 'starting your app' , i m reaaly fed up with this :|

[poojabhimte16]

@baloodevil , Hey are u aware of latest version of Meteor, which is 1.3

[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.

[NitroBAY]

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.

[NitroBAY]

@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.

[NitroBAY]

Totally agree with @dtruel

[ThomsCass]

+1

[NitroBAY]

@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?

[Slava]

I no longer work at Meteor, but I do use it for a dozen of apps I built for student organizations I am in.

I also run Windows 10 on my personal MS-produced laptop (that was a mistake, but it is too late to switch now).

After updating my Windows 10 to insider edition, I switched all my development to the Linux subsystem. It works so much better than any other Windows workflow I ever had. I run all my software as it is designed and can even run GUI programs (like my Emacs) with an Xserver running on Windows side. The only hiccup is slow FS, but that's a problem inherit to Windows.

Anyway, as one of the 3 people working on the Windows port for Meteor for over 6 month, I really really wish Microsoft released Linux subsystem earlier. In that case it would save me and my teammates thousands of work hours that could go into something better.

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

I actually believe this would be the most fitting solution and let me tell you why I think so:

• Supporting Windows drains a lot of energy and effort from a small development team like MDG
• Supporting Windows is so difficult because all tooling is different and seemingly harder to setup: testing, CI, delivery (won't even start on the installers, signing binaries with Ubikeys, pulling in ancient compiler toolchain just to make sure installer would run smoothly on all machines)
• In the end of the day, node on Windows still is crap: node_modules exceed 256 char limit, memory leaks, native modules are hard to compile, FS changes are hard to track. The Meteor developer experience will still be inferior even if MDG puts more hours into this.

[gdoteof]

@brettg2

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

I feel like you are being sarcastic here (not that I blame you), but actually yes, I do believe that is the answer to this problem. When this thread was opened, the linux subsystem on windows was not widely available.

Now it is widely available however, so there is no need to use a windows specific fork. I would expect/recommend meteor to deprecate the windows version entirely and jsut recommend people to use the linux subsystem. ( I also expect this of the wider JS community ).

[hwillson]

All - this is definitely an interesting discussion, but please note that this issue thread was closed due to a lack of specific details to act on. If anyone is still encountering performance problems while using Meteor on Windows, please open a new issue with as much information as you can provide relating to the issue you're seeing (see Reporting a bug in Meteor).

While switching to use Meteor on *nix or MacOS is a viable option for some, moving away from Windows is still not an option for many (especially within the corporate world). I agree that the Windows Subsystem for Linux looks super promising, and leveraging it might be the future of Meteor on Windows. Given that Windows 7/8 are still going to be around for a while however, we should make sure non-bleeding edge Windows users can still use Meteor.

Please Windows users - open new issues with your problems, and provide as many details as you can. Better yet, jump in and help try to track those problems down (like @steph643 has been doing - e.g. https://github.com/meteor/meteor/issues/8485#issuecomment-315533298). Thanks!

[Slava]

Thanks @hwillson,

I definitely didn't intend to make my comment sound as negative as it turned out to be. I think a helpful bit would be a wiki-like page with all tip and common advice of running Meteor on Windows.

For example: make sure your antivirus is not hogging CPU checking generated files. Or don't run Meteor on virtualized filesystem - they tend to be slow.

[mizzao]

@Slava when you say virtualized FS do you mean the WSL lxss filesystem, or the NTFS file system accessed from WSL?

Glad to hear everything is humming on WSL with Windows 10. I have been doing that for a while but was scared of running into unexpected surprises :)

[hwillson]

I didn't take your comment to be negative at all @Slava! Actually, I think it's quite helpful; many people are in a position to be able to try out Meteor + Windows Subsystem for Linux, so knowing that you've had a lot of luck with it is great news! I just wanted to re-iterate to Windows users that Meteor needs their help. The number of reported Windows issues keeps growing (more than almost all other categories of issues it seems ... well, except for Cordova), so please help everyone! 🙂

I think a helpful bit would be a wiki-like page with all tip and common advice of running Meteor on Windows.

Yes, definitely - or maybe a section in the Guide?

[Slava]

@mizzao I mean lxss filesystem is slower than a native Linux FS directly accessing hardware (well through OS layers). Accessing NTFS on Windows 10 from WSL never works for me well. I stopped doing that fearing to lose files. For example, my dropbox(on windows) can't sync files that I wrote from WSL.

[mizzao]

@Slava For me, the problem with that is I can't use Windows-based editors (e.g. VS Code) to edit files on the lxss FS. So I install Meteor in lxss, but have the git repos checked out on NTFS. The editor saves files to NTFS, and Meteor reaches into NTFS. Sometimes, it creates a bit of an issue with cross-platform line endings. Have you found a better way?

Also - which XServer are you using for Windows?

[Slava]

This is kinda offtopic, but if this helps anyone to run Meteor in WSL:

I added this to my .bash_profile: export DISPLAY=localhost:0. Then on Windows side I run VcXsrv Windows X server. Now I can run emacs from linux and it will create a window on the Windows side. I suspect this should work for Atom and other editors too, but I haven't tried.

[mizzao]

I wrote up something like that here (https://askubuntu.com/a/867696/86161) as well. The downside is that I wanted to try and use editors from Windows rather than the not-well-supported roll your own XServer approach.

Anyway, I agree that this was a little off topic, but might help future people who see this post.

[CaptainN]

Windows re-build times are still very very slow with a couple of places in the process that feel like something is timing out - and it seems to get slower over time (ramping up somewhat quickly). (December 2018)

I went from a minute and a half to two minute rebuild times (with a stop watch, I clocked a 30 second pause, and another almost 60 second pause at the end, at various stages of rebuild) on Windows. I have since switched to always running Meteor inside a Linux VM (Ubuntu) after trying literally dozens of other things, which you can read about here: https://forums.meteor.com/t/making-windows-less-slow-defender/45132/41 Rebuild times went from over 90 seconds to under 10 seconds on the same hardware.

It's so slow, I'd say it's broken (on top of the very slow and fragile install process through chocolatey which is a whole other thing). IMO, MDG should seriously consider pulling the current Windows port if a fix is not coming in the short term. The developer experience is that problematic.

It would probably be less hassle and headache to require a VM for Meteor development on Windows (I'm quite delighted now that I finally got that working right). I had some interns who were on Windows, and they also reported that it was slow. I didn't understand exactly how slow until I switched to Windows a few weeks after their internships had ended (when my MacBook Pro died). Those interns were unsuccessful in submitting much useful to my project compared with interns on Linux and macOS, and probably don't ever want to touch Meteor again.

It's unusably slow. I'm happy to open a new issue for this if it would be helpful. I'd also be happy to try as best I can to work out exactly why it's so slow, but I'll need some guidance on figuring it out.

[andrei-markeev]

Don't quite agree. I did have issues back in 2016, but during 2017-2018 the performance has actually been quite good.

CSS update ~1-2 seconds (hot reload), client-side update ~2-3 seconds + time necessary for page reload, server-side update 4-5 seconds + time for executing your code in server-side Meteor.startup. The worst case is when code shared between client and server is updated, then it's ~15 seconds + page reload in my setup.

So I would say, there're certain configurations of Meteor that work well on Windows. Certain configurations don't. Meteor is so flexible and can be used in so many fashions and flavors, and changed so much over the years, I guess it's hard for MDG to keep track of all of those even on one system, let alone cross-platform.

Myself, I am very grateful to MDG guys to all the work they did, Meteor introduced so many amazing things back in 2012, we, Meteor people, were literally living in the future all these years. E.g. hot reload became mainstream only in ~2017. And websocket-based live applications? World is still far behind.

According to my observations, this is what can affect rebuild performance:

• version of Meteor
• build plugins you're using (e.g. barbatus:typescript, jade, static-html, etc.)
• how files are structured into folders (server, client, imports)
• amount of files
• size of npm dependencies
• Windows Defender

Things of note (!):

• even though Meteor uses caching compilers, amount of files and size of npm dependencies still slightly affects rebuild performance, because _all_ files are passed into build plugin
• some Meteor modules can be build plugins even though you think they aren't. A single build plugin that does something that Windows doesn't like, can drastically reduce performance
• even though based on documentation, it might seem that imports folder don't need splitting to client and server folders, if you don't split, all files inside imports are treated as shared and cause full rebuild
• do either meteor reset from time to time (this destroys your local database though), or alternatively remove all folders except db from .meteor/local - same effect, but db will be preserved.
• check performance after every update of meteor and meteor modules - things do get better sometimes, but sometimes they get worse

[CaptainN]

The thing is, my rebuilds went from 90+ seconds, to under 10 seconds, just by moving to a VM (on the same hardware, even debugging using the same browsers in Windows, and still editing the files in Windows, though not on a Windows drive - everything is stored within the VM).

I love Meteor too, that's why I'd like to help fix this - or if Windows is going to be this problematic, ask MDG to seriously consider dropping the platform. The same app can't have this level of performance disparity when compiled on Windows vs. Linux - regardless of how the app is structured.

Based on issue #10185 I'm not entirely sure this a Windows problem. I had described in that forum thread that the rebuild process appears to stall at various points - two in particular. There is a huge stall right before the server says it has restarted in the terminal, then another AFTER the server says it has restarted - it takes like 30-50 seconds for the browser to be able to access the server again. I thought this was something on windows, but it looks like @houshuang is not on Windows, yet seeing the same thing, so I'm not sure.

[andrei-markeev]

The discrepancy is unfortunate indeed. I would, however, prefer restructuring my files rather than moving to a VM. I also have Mac laptop and Linux laptop, ...but still prefer to restructure the files.

My point is, please don't forget that preferences might be different. I agree that it would be great if build performance on Windows was optimized same way as on Linux/Mac, however MDG dropping Windows platform completely - that could be quite disastrous for some people, for me at least.

[CaptainN]

I guess dropping it may not be in the cards. The problem though, is that I exposed Meteor to several interns who were on Windows. I'm sure none of them will be happy to ever user Meteor again (they said as much, and because I was not on Windows, I didn't understand the problem - this itself is a problem).

[CaptainN]

BTW, I actually did try to restructure my app (I had forgot about that) - I removed SSR, and removed everything from /imports. I first tried it in /src, just to see what impact that would have, then moved everything into either /client or /server enough to make the app work. Neither of these restructures helped the problem I'm seeing on Windows. It still stalls at various points during rebuild. Maybe I should make a separate ticket for that specific problem.

[steph643]

@CaptainN, you might want to test with a shorter folder path. A long path used to cause issues (see https://github.com/meteor/meteor/issues/8801 for example).

[CaptainN]

Just to see if anything has changed, I updated my Windows copy of my project repo (my most recent largish project) to get it up and running on windows - it took 10 minutes just to update Meteor! Then I updated npm packages (very fast, no problems there), then turned on Meteor - MINUTES later, I had a server up!

Rebuilds continue to be slow. According to my stop watch, at 17 seconds it notices my file changed, at 1 minute (almost exactly) it says the server restarted- at 1 minute 40 seconds the browser is able to actually update the page (40 seconds just waiting for the browser with no feedback).

Same branch in the VM (same hardware) took 28 seconds, and the server was available immediately after it said it restarted.

So there are two big delays (front and back) and some general slowness in the middle. The general slowness in the middle could be tolerable - 43 seconds vs. 28 seconds is not great, but not the worst. Maybe I should put in a separate ticket at least for that 40 post restarted delay.

[CaptainN]

@steph643 I tried moving the app to c:/repos/myapp instead of my usual location c:/Users/Kevin/repos/myapp . One thing I haven't mentioned in this thread is how flaky the meteor command is in general on Windows - much of the time it doesn't actually start the app, usually exiting with some various mongo error. So that happened after 15 minutes for the initial start (I had only copied the repo folder, not .meteor/local, so that had to be freshly built). After that, rebuild is similar, 54 seconds to get to "server restarted" - then again 40 seconds before the browser can reach the server.

Honestly, it's too much work to try and restructure my app to work faster on Windows - it works perfectly fine on macOS and Ubuntu, and my Ubuntu VM is faster and better in various other ways anyway (better command line tools, my scripts work as I expect - I can set environment vars in the start command!). I'll just keep running it in there, but MDG should take a serious look at their Windows product offering - from a product owner perspective, it's not good.

[benjamn]

@CaptainN Can you try building/rebuilding your app using either --extra-packages qualia:profile or $env.TOOL_NODE_FLAGS = "--inspect-brk" and profiling using the Chrome dev tools? The native Node profiling tools may be able to break down the performance in a more fine-grained way than you get with the METEOR_PROFILE=20 environment variable. Happy to elaborate if any of these suggestions doesn't make sense.

[CaptainN]

@benjamn I'll give that a try. I'm also working on a reduction for at least the post-restart delay. So far with a fresh project I get no delay, so I'm trying to build back up piece by piece to my full (slow) app to see where the problem is coming from.

[CaptainN]

I'm not able to install qualia:profile

While loading package qualia:[email protected]:
error: Command failed: C:\WINDOWS\system32\cmd.exe /c C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\bin\npm.cmd rebuild
--update-binary
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit
(C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\lib\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at emitTwo (events.js:126:13)
gyp ERR! stack     at ChildProcess.emit (events.js:214:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\bin\\node.exe"
"C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\lib\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js"
"build" "--fallback-to-build"
"--module=C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\qualia_profile\\0.0.12\\plugin.qualia_profile.os\\npm\\node_modules\\meteor\\qualia_profile\\node_modules\\.temp-1495kz4.skdj\\node_modules\\v8-profiler-node8\\build\\profiler\\v6.0.0\\node-v57-win32-x64\\profiler.node"
"--module_name=profiler"
"--module_path=C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\qualia_profile\\0.0.12\\plugin.qualia_profile.os\\npm\\node_modules\\meteor\\qualia_profile\\node_modules\\.temp-1495kz4.skdj\\node_modules\\v8-profiler-node8\\build\\profiler\\v6.0.0\\node-v57-win32-x64"
"--napi_version=3" "--node_abi_napi=napi"
gyp ERR! cwd
C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8
gyp ERR! node -v v8.11.4
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute 'C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\bin\node.exe
C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\lib\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js build
--fallback-to-build
--module=C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8\build\profiler\v6.0.0\node-v57-win32-x64\profiler.node
--module_name=profiler
--module_path=C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8\build\profiler\v6.0.0\node-v57-win32-x64
--napi_version=3 --node_abi_napi=napi' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous>
(C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\lib\node_modules\node-pre-gyp\lib\util\compile.js:83:29)
node-pre-gyp ERR! stack     at emitTwo (events.js:126:13)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:214:7)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:925:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
node-pre-gyp ERR! System Windows_NT 10.0.17134
node-pre-gyp ERR! command "C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\bin\\node.exe"
"C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\lib\\node_modules\\node-pre-gyp\\bin\\node-pre-gyp" "install"
"--fallback-to-build"
node-pre-gyp ERR! cwd
C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8
node-pre-gyp ERR! node -v v8.11.4
node-pre-gyp ERR! node-pre-gyp -v v0.10.3
node-pre-gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: `node-pre-gyp install --fallback-to-build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Kevin\AppData\Roaming\npm-cache\_logs\2018-12-06T18_49_43_772Z-debug.log
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit
(C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\lib\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at emitTwo (events.js:126:13)
gyp ERR! stack     at ChildProcess.emit (events.js:214:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\bin\\node.exe"
"C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\lib\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js"
"build" "--fallback-to-build"
"--module=C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\qualia_profile\\0.0.12\\plugin.qualia_profile.os\\npm\\node_modules\\meteor\\qualia_profile\\node_modules\\.temp-1495kz4.skdj\\node_modules\\v8-profiler-node8\\build\\profiler\\v6.0.0\\node-v57-win32-x64\\profiler.node"
"--module_name=profiler"
"--module_path=C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\qualia_profile\\0.0.12\\plugin.qualia_profile.os\\npm\\node_modules\\meteor\\qualia_profile\\node_modules\\.temp-1495kz4.skdj\\node_modules\\v8-profiler-node8\\build\\profiler\\v6.0.0\\node-v57-win32-x64"
"--napi_version=3" "--node_abi_napi=napi"
gyp ERR! cwd
C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8
gyp ERR! node -v v8.11.4
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute 'C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\bin\node.exe
C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\lib\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js build
--fallback-to-build
--module=C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8\build\profiler\v6.0.0\node-v57-win32-x64\profiler.node
--module_name=profiler
--module_path=C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8\build\profiler\v6.0.0\node-v57-win32-x64
--napi_version=3 --node_abi_napi=napi' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous>
(C:\Users\Kevin\AppData\Local\.meteor\packages\meteor-tool\1.8.0_1\mt-os.windows.x86_64\dev_bundle\lib\node_modules\node-pre-gyp\lib\util\compile.js:83:29)
node-pre-gyp ERR! stack     at emitTwo (events.js:126:13)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:214:7)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:925:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
node-pre-gyp ERR! System Windows_NT 10.0.17134
node-pre-gyp ERR! command "C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\bin\\node.exe"
"C:\\Users\\Kevin\\AppData\\Local\\.meteor\\packages\\meteor-tool\\1.8.0_1\\mt-os.windows.x86_64\\dev_bundle\\lib\\node_modules\\node-pre-gyp\\bin\\node-pre-gyp" "install"
"--fallback-to-build"
node-pre-gyp ERR! cwd
C:\Users\Kevin\AppData\Local\.meteor\packages\qualia_profile\0.0.12\plugin.qualia_profile.os\npm\node_modules\meteor\qualia_profile\node_modules\.temp-1495kz4.skdj\node_modules\v8-profiler-node8
node-pre-gyp ERR! node -v v8.11.4
node-pre-gyp ERR! node-pre-gyp -v v0.10.3
node-pre-gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: `node-pre-gyp install --fallback-to-build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Kevin\AppData\Roaming\npm-cache\_logs\2018-12-06T18_49_43_772Z-debug.log

[CaptainN]

I tried to install node-pre-gyp globally (outside of meteor, like I did for windows-build-tools to get bcrypt working) with npm i -g node-pre-gyp then run the suggested command node-pre-gyp install --fallback-to-build but it tells me my package.json file is missing certain values, including some binary names. (I tried fudging those values, but I don't know what they should be, and it didn't work. I'll try the Chrome method - if I can figure out how to set that env variable on Windows...)

[CaptainN]

I changed my start script to: "start": "set TOOL_NODE_FLAGS=\"--inspect-brk\" & meteor run --settings development.settings.json -p 3000" then ran my app. Attached is a startup profile (took forever, but I missed the first few seconds), and also a rebuild profile.

For the rebuild profile I started it, then made a change to a file, then waited until the browser was able to load from the server.

startup.zip
rebuild.zip

(Windows Defender is disabled.)

[vikas0121]

this is a meteor issue, it downloading sources one at a time in debug mode. to fix this add a --production flag

How to add production flag?