Meteor: Meteor build time/refresh time after file save is VERY slow

[cdcv]

_4 Upvotes_ I have reasonably large app that I'm working on.
When I make any change to the code and press 'save', the time to build the app and refresh the browser is very long, and also highly variable. It is typically 30-60s.
A colleague is working on the same app, and is using a similar machine (both are 1-2 year old high-end MacBook Pro), and in his environment the build time is typically <5s.
When I make changes to a small demo project, the refresh time is <2-3s.
I have tried a bunch of things, including reinstalling meteor, but to no avail.
This is bringing development to its knees.
What can I do?

Thank you for your help?

[ekatek]

Hm. That's kind of whacky (we do have an Isobuild:Performance label for just this sort of issues!). Unfortunately, it is very hard for us to debug this without a reproduction. Do you have any idea what sort of complexity could be causing this -- how is your app structured (lots of packages, for example)? How large of an app are we talking about? What are example of file changes that do or don't cause this/is there a pattern?

I'll leave this issue open -- maybe someone actively working on the Isobuild:Performance project will come up with more theories; or we will fix this in one of our constantly-upcoming refactorings. Unfortunately, right now, there is not much that we can do directly without more information.

[cdcv]

Thanks for your message.
I've been trying to figure out how to get to the bottom of this, and haven't had much success.
The biggest reason is that there seems to be great variability in the refresh times. For example, sometimes I set the code one way to test it, get a 'good' refresh time like 15s, then change it again and get 20s, and then get about 5s more for each additional time that I make a change and hit save.
This kind of thing makes it more or less impossible to try to figure out what in the code is causing the issues.
There does seem to be an important aspect related to system resources. When I clear out other running programs on my Mac, things can get much better (but still not very good).
I've tried removing different parts of the app, and while it certainly gets fast if I cut out most of it, I haven't been able to succeed in isolating an issue.
The app uses a few dozen packages. Not sure how you'd like me to quantify how 'large' the app is. Pretty big...?

Sure would be good to be able to fix this.
Other people haven't been experiencing slow refresh times?
Thanks for your help.

[rclai]

One thing that might help that has helped us with our giant app which also takes forever to reload is to short circuit the hot code reload by clicking the address bar in the browser and hit enter. Do not hit F5 or the browser's reload button.

[pierreozoux]

I'm dying also under refresh time, the same, like between 30-60s :/

The code is here if you want to check (I'm quiet new to meteor, and I know there are rooms for improvement): https://github.com/pierreozoux/TioApp

I found a quiet good solution:

meteor remove sanjo:jasmine velocity:html-reporter velocity:console-reporter

The drawback is that you don't have tests anymore, does it help on your side @cdcv ?

[csto]

I feel your pain @pierreozoux . My app takes 30-45 seconds to refresh and I would consider it a small app. This does not bode well for Meteor. I have tried the app on multiple high end macbooks and they all take about the same amount of time.

[Slava]

We are aware of this problem and working on the improvements. In the meanwhile, I must mention that packages get better caching as of today. So if you split up your app into packages, the rebuild time should be much better.

[mitar]

Are there any recent improvements in build times?

[pajooh]

I'm facing the same issue, my app initially forked from Telescope,
the build/refresh time is very annoying

[robertpitt]

Have you tried running with profiling enabled, to help spot where the bulk of the time is being used up.

METEOR_PROFILE=1 meteor

regards.

[pajooh]

@robertpitt thank you. i was not aware of this option. however it seems that it can not help
the profiling is ending before the actual wasting time is started. i.e. when the profiler prints its output and the Client modified -- refreshing is printed, the browser takes much time after that to load the new app.

[robertpitt]

Sounds like it's Velocity related to me, Ive tried your app on my i3/4GB laptop and get < 1 second to load the client up after a build..

Give this a try and see if you can see anything funky:

VELOCITY_DEBUG=1 VELOCITY_DEBUG_MIRROR=1 METEOR_PROFILE=1 meteor

[pajooh]

here is the command output from my i5/4GB laptop:

| Select Package Versions: 2563.9
|     new CS.Input: 5.1
|     Input#loadFromCatalog (sqlite): 1606.3
|     check for previous versions in catalog: 0.4
|     new CS.Solver: 53.9
|         Solver#analyze: 53.8
|             analyze allowed versions: 6.0
|             analyze root dependencies: 0.8
|             analyze reachability: 6.2
|             analyze constraints: 39.8
|             analyze pre-releases: 0.9
|             other Solver#analyze: 0.2
|         other new CS.Solver: 0.1
|     Solver#getAnswer: 898.1
|         new Logic.Solver (MiniSat start-up): 3.9
|         require root dependencies: 1.2
|         generate package variables: 229.2
|         generate dependency requirements: 94.5
|         generate constraints: 151.4
|         pre-solve: 202.0
|         forbid packages with no matching versions: 0.0
|         minimize unknown_packages: 0.8
|         minimize conflicts: 92.6
|         minimize unanticipated_prereleases: 0.6
|         calculate previous_root distance costs: 4.2
|         add terms to previous_root_incompat: 0.0
|         minimize previous_root_incompat: 22.0
|         calculate update version costs: 0.0
|         minimize update_major: 0.0
|         minimize update_minor: 0.0
|         minimize update_patch: 0.0
|         minimize update_rest: 0.0
|         minimize previous_root_major: 0.5
|         minimize previous_root_minor: 1.6
|         minimize previous_root_patch: 1.6
|         minimize previous_root_rest: 0.1
|         calculate previous_indirect distance costs: 5.0
|         minimize previous_indirect_incompat: 9.4
|         minimize previous_indirect_major: 0.9
|         minimize previous_indirect_minor: 10.2
|         minimize previous_indirect_patch: 3.5
|         minimize previous_indirect_rest: 0.5
|         calculate new_root version costs: 0.0
|         minimize new_root_major: 0.0
|         minimize new_root_minor: 0.0
|         minimize new_root_patch: 0.0
|         minimize new_root_rest: 0.0
|         lock down important versions: 8.3
|         calculate new_indirect version costs: 0.2
|         minimize new_indirect_major: 0.0
|         minimize new_indirect_minor: 0.2
|         minimize new_indirect_patch: 0.1
|         minimize new_indirect_rest: 0.0
|         minimize total_packages: 48.8
|         generate version map: 1.1
|         other Solver#getAnswer: 3.6
|     other Select Package Versions: 0.2
| 
| Input#loadFromCatalog (sqlite): 1606.3
| generate package variables: 229.2
| pre-solve: 202.0
| generate constraints: 151.4
| generate dependency requirements: 94.5
| minimize conflicts: 92.6
| minimize total_packages: 48.8
| analyze constraints: 39.8
| minimize previous_root_incompat: 22.0
| minimize previous_indirect_minor: 10.2
| minimize previous_indirect_incompat: 9.4
| lock down important versions: 8.3
| analyze reachability: 6.2
| analyze allowed versions: 6.0
| new CS.Input: 5.1
| calculate previous_indirect distance costs: 5.0
| calculate previous_root distance costs: 4.2
| new Logic.Solver (MiniSat start-up): 3.9
| other Solver#getAnswer: 3.6
| minimize previous_indirect_patch: 3.5
| minimize previous_root_patch: 1.6
| minimize previous_root_minor: 1.6
| require root dependencies: 1.2
| generate version map: 1.1
| minimize previous_indirect_major: 0.9
| analyze pre-releases: 0.9
| minimize unknown_packages: 0.8
| analyze root dependencies: 0.8
| minimize unanticipated_prereleases: 0.6
| minimize previous_indirect_rest: 0.5
| minimize previous_root_major: 0.5
| check for previous versions in catalog: 0.4
| other Select Package Versions: 0.2
| calculate new_indirect version costs: 0.2
| other Solver#analyze: 0.2
| minimize new_indirect_minor: 0.2
| minimize new_indirect_patch: 0.1
| other new CS.Solver: 0.1
| minimize previous_root_rest: 0.1
| minimize new_indirect_rest: 0.0
| minimize new_indirect_major: 0.0
| forbid packages with no matching versions: 0.0
| minimize update_major: 0.0
| minimize new_root_major: 0.0
| minimize update_minor: 0.0
| minimize update_patch: 0.0
| minimize update_rest: 0.0
| minimize new_root_rest: 0.0
| minimize new_root_minor: 0.0
| minimize new_root_patch: 0.0
| add terms to previous_root_incompat: 0.0
| calculate update version costs: 0.0
| calculate new_root version costs: 0.0
| Total: 2563.9
| 
| files.readFile: 0.4
| files.exists: 0.1
| Rebuild App: 4623.1
|     Isopack#getUnibuildAtArch: 1.5
|     Isopack#_ensurePluginsInitialized: 0.0
|     files.readdir: 4.9
|     files.stat: 26.5
|     files.realpath: 3.3
|     files.readFile: 35.8
|     bundler.bundle..makeClientTarget: 3715.2
|         Target#make: 3715.1
|             Isopack#getUnibuildAtArch: 14.5
|             Unibuild#getResources: 217.3
|                 Isopack#getUnibuildAtArch: 18.9
|                 other Unibuild#getResources: 198.4
|             ClientTarget#mergeCss: 3398.2
|             other Target#make: 85.0
|         other bundler.bundle..makeClientTarget: 0.2
|     bundler..writeTargetToPath: 271.9
|         files.rm_recursive: 0.3
|         files.stat: 0.7
|         files.mkdir: 0.2
|         ClientTarget#write: 243.6
|             Builder#reserve: 10.1
|                 files.mkdir: 2.6
|                 other Builder#reserve: 7.4
|             Builder#writeToGeneratedFilename: 48.8
|                 Builder#generateFilename: 9.6
|                     Builder#_sanitize: 4.7
|                     Builder#reserve: 2.8
|                     other Builder#generateFilename: 2.1
|                 Builder#write: 37.2
|                     Builder#_ensureDirectory: 1.3
|                     files.writeFile: 31.4
|                     other Builder#write: 4.5
|                 other Builder#writeToGeneratedFilename: 2.0
|             bundler..writeFile: 131.8
|                 Builder#write: 129.5
|                     Builder#_ensureDirectory: 5.5
|                     files.writeFile: 109.6
|                     other Builder#write: 14.4
|                 other bundler..writeFile: 2.2
|             Builder#writeJson: 5.3
|                 Builder#_ensureDirectory: 0.0
|                 files.writeFile: 0.5
|                 other Builder#writeJson: 4.8
|             other ClientTarget#write: 47.7
|         Builder#complete: 26.7
|             files.rename: 0.3
|             files.rm_recursive: 26.4
|             other Builder#complete: 0.1
|         other bundler..writeTargetToPath: 0.4
|     other Rebuild App: 564.0
| 
| ClientTarget#mergeCss: 3398.2
| other Rebuild App: 564.0
| other Unibuild#getResources: 198.4
| files.writeFile: 141.4
| other Target#make: 85.0
| other ClientTarget#write: 47.7
| files.readFile: 36.3
| Isopack#getUnibuildAtArch: 34.9
| files.stat: 27.1
| files.rm_recursive: 26.7
| other Builder#write: 18.9
| other Builder#reserve: 7.4
| Builder#_ensureDirectory: 6.9
| files.readdir: 4.9
| other Builder#writeJson: 4.8
| Builder#_sanitize: 4.7
| files.realpath: 3.3
| files.mkdir: 2.9
| Builder#reserve: 2.8
| other bundler..writeFile: 2.2
| other Builder#generateFilename: 2.1
| other Builder#writeToGeneratedFilename: 2.0
| other bundler..writeTargetToPath: 0.4
| files.rename: 0.3
| other bundler.bundle..makeClientTarget: 0.2
| files.exists: 0.1
| other Builder#complete: 0.1
| Isopack#_ensurePluginsInitialized: 0.0
| Total: 4623.6
=> Client modified -- refreshing

as i said, the major reload time(~30seconds) occures after Client modified -- refreshing

[robertpitt]

Although I would love to help, I think we are filling the issue tracker up with client related performance issues, not specifically a problem with meteor but an edge case based on your hardware and a specific set of code.

As this is specifically happening on your machine and the application runs very fast for me and your colleagues, you will just have to dig further and use StackOverflow as a resource for this one.

Sorry I can't help.
Good Luck.

[ORESoftware]

hello people! doesn't Meteor have LiveReload / Hot reloading / Hot Code Push (HCP)? This would de-necessitate a full rebuild. Or am I mistaking what HCP is? Seems like HCP meaning has been changed from hot reload to push changes to mobile devices.

http://info.meteor.com/blog/hot-code-pushes

https://github.com/NucleusIDE/meteor-live-update

SO CONFUSED RIGHT NOW

[dud3]

I thought I was the only one having this issue, rebuilding it takes ages, meh ;(.

[mxs]

With react there is https://gaearon.github.io/react-hot-loader/ which hotloads and keeps state in about 1 to 2 secs.

For those that are using ReactJs with Meteor there is: https://github.com/jedwards1211/meteor-webpack-react/
Which I am keen to try out. Initial look seems to provide the best of both worlds.

[ORESoftware]

Hot reloading with Meteor should be an option so you don't have restart the server - but I can't get any information as to whether this is currently a working feature. Hot reloading with React will not work with Meteor, since Meteor is so different. There is no way it will work, since react-hot-loader works with Webpack, not Meteor's build system.

[mxs]

Apologies, the second link is incorrect from above. Should be https://github.com/jedwards1211/meteor-webpack-react/

Which uses Webpack to package instead of Meteor. It seems a little bit hacky with symlinks but there are quite a few huge benefits such as Hot loading for React components and using npm directly.

[thesunny]

This is a far superior solution to meteor-webpack-react. Easier to understand and relatively easy to setup, even on an existing project. This came out very recently and I'm a fan already.

https://github.com/thereactivestack/meteor-webpack-react-kickstart

I had to switch to this as waiting for rebuilds was too frustrating for me. Unfortunately, this doesn't solve the build time issues on the server. I really wish we could do hot loading on the server using something like a server side version of WebPack.

The downside is it's a little bit harder to get started but as soon as your project is of a decent size, the load times kill you much more than the extra little bit of verbosity.

[ORESoftware]

no offense, but trying to get meteor to work with the webpack build system module loader sounds like a nightmare. the Meteor team should be working to create a "native" solution. Trying to get hot reloading functionality to work with Meteor by incorporating webpack's hot module replacement sounds like a horrible horrible idea where you will spend more time debugging your hot reloading features than coding your app.

I have done a bit of research on hot reloading and here is some information if you are interested:
https://medium.com/@the1mills/hot-reloading-with-react-requirejs-7b2aa6cb06e1

I recommend watching Dan Abramov's video before anything

[hitchcott]

Interesting article @ORESoftware but I think you have the wrong impression:

Meteor added hot reloading support as early as 2012, but as far as I can tell it is deprecated, or at least depreciated

This is false; hot-code-push is not deprecated - there's just a performance bug for some people in this issue, probably due to some configuration or hardware quirk.

It is most definitely supported natively, and you should expect to have hot code pushes extremely quickly in most situations. On fresh Meteor projects, for me, they happen in less than a second for CSS updates and within a few seconds for markup/js.

[ORESoftware]

but then I don't understand why build times are such an issue and I also
was under the impression that HCP was intended for a different purpose -
pushing updates to devices already running your app, and wasn't for
development. Basically hot reload for production. I will look for a link to
that info.
On Sep 18, 2015 3:32 AM, "Chris Hitchcott" [email protected] wrote:

Interesting article @ORESoftware https://github.com/ORESoftware but the
stuff I think you have the wrong impression:

Meteor added hot reloading support as early as 2012, but as far as I can
tell it is deprecated, or at least depreciated

This is false; hot-code-push is not deprecated - there's just a
performance bug for some people, probably due to some configuration or
hardware quirk.

You should expect to have hot code pushes extremely quickly - on fresh
Meteor projects, for me, they happen in less than a second for CSS updates
and within a few seconds for markup/js.

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

[ORESoftware]

see this article on Meteor soft code push vs hard code push

https://meteor.hackpad.com/Hot-Code-Push-design-notes-9o22fy6gruu
On Sep 18, 2015 10:25 AM, "Alexander Mills" [email protected] wrote:

but then I don't understand why build times are such an issue and I also
was under the impression that HCP was intended for a different purpose -
pushing updates to devices already running your app, and wasn't for
development. Basically hot reload for production. I will look for a link to
that info.
On Sep 18, 2015 3:32 AM, "Chris Hitchcott" [email protected]
wrote:

Interesting article @ORESoftware https://github.com/ORESoftware but
the stuff I think you have the wrong impression:

Meteor added hot reloading support as early as 2012, but as far as I can
tell it is deprecated, or at least depreciated

This is false; hot-code-push is not deprecated - there's just a
performance bug for some people, probably due to some configuration or
hardware quirk.

You should expect to have hot code pushes extremely quickly - on fresh
Meteor projects, for me, they happen in less than a second for CSS updates
and within a few seconds for markup/js.

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

[ORESoftware]

actually this is the better link:

http://info.meteor.com/blog/meteor-hot-code-push

so yeah I can't really find any good information about hot reloading with Meteor, any information on hot reloading as a means to avoid server restarting would be useful to me

[ORESoftware]

IMO, Meteor needs to do a better job making the distinction between Hot Code Push and Hot Reloading, one is for production the other for development, so that's at least one difference

[rclai]

It is important to make the distinction, if it wasn't made already, that the Hot code push of Webpack (React Transform) functions differently from that of Meteor's. Webpack's React transform will update the React components on the fly without tampering with the state and without reloading your browser, whereas Meteor's hot code reload will do a browser reload without tampering with the Session state only.

[ORESoftware]

I see, that's good info thanks

[mxs]

@thesunny thank you for pointing me to https://github.com/thereactivestack/meteor-webpack-react-kickstart. It works wonderfully. :+1: It is implemented much more inline with the 'webpack' and 'Meteor' way compared to the earlier solution I posted.

[thesunny]

@mxs You're welcome. I'd also recommend removing redbox from the webpack config settings. It makes it so that the line numbers are reported incorrectly on the error messages. This wastes time looking for where the actual error occurred. Furthermore, for my app, the redbox error message was covered by some "position: fixed;" divs.

The author has indicated that he won't remove redbox but will try to find a fix for the line numbers.

[dud3]

Any progress on this one ? I ran out of coffee while waiting for it to rebuilt.

[sangyoo91]

... I just stumbled upon the same problem...

I am dying waiting :l

[ORESoftware]

get Meteor to support hot reloading to the fullest

[efatsi]

Followed install instructions and working through the Simple Todo app tutorial is taking 3-4 seconds for rebuilding. Seems pretty rough for such a basic app.

[seanodotcom]

Same here. Just halfway through the TODO tutorial, and it's taking over _10 seconds_ to rebuild after every save. On Win 8.1 Pro, with a 3.7Ghz Xeon, 256GB SSD, and 16GB of RAM.

[NazarK]

Not exactly a solution: Some small client functions (or collection helpers for example) can be copied from editor and pasted directly to browser console (without saving file to disk to avoid meteor rebuild).

I think should be possible to build some meteor plugin that will reload just one file if it has some specific name.

[quape]

Same for me, small app but 25 secs waiting time after every file save :-( This issue should be top priority. It's not possible to work like this.

[pyoungerv]

agreed. any updates?

[ORESoftware]

just a note: if you so happen to be using a machine with a hdd instead of a
solid state drive you will mostly experience 3x- 5x build times
On Oct 19, 2015 8:59 AM, "pyoungerv" [email protected] wrote:

agreed. any updates?

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

[zaklampert]

+1. Also having long (45s) reload times on our react meteor app.

EDIT: Just tried @rclai 's approach (short circuiting rather than waiting for the browser to refresh on it's own) and it's actually much faster. Any idea why?

[ghost]

@zaklampert
are you using browserify? then that is expected.
are you using webpack? I guess not.

On Mon, Oct 19, 2015 at 11:08 PM, zaklampert [email protected]
wrote:

+1. Also having long (45s) reload times on our react meteor app.

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

[zaklampert]

@casperanderseneu really, 45s for a reload time is expected? YIkes.

I've started creating a webpack version of our app using starter kit mentioned above. Looks promising.

[rclai]

@zaklampert, I have no clue why reloading the way I described above is faster. I've been using the Webpack boilerplate now though.

[ghost]

@zaklampert
Currently thereactivestack/meteor-webpack is the leader of the pack.
alternatives previously encountered:

• meteor-rocket/webpack and module
• jedwards1211/webpack

over and out

@stubailo
why the react in meteor guide still suggests browserify is beyond me.

On Mon, Oct 19, 2015 at 11:46 PM, Richard Lai [email protected]
wrote:

@zaklampert https://github.com/zaklampert, I have no clue why reloading
the way I described above is faster.

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

[stubailo]

@casperanderseneu what would that guide look like with webpack?

[ghost]

@stubailo webpack, that's the question. let's find out.

[quangv]

just had to +1, hopefully problem gets fixed...

[NazarK]

Isn't meteor 1.2 solving this problem?
From release notes: We've also got a new build pipeline in Meteor 1.2 that rebuilds much faster (especially on large code bases),

[quangv]

so I fixed it for myself.

It might sound too obvious, but for me, I did a "Repair Disk Permissions", also "Repair Disk".

My Mac is overall quicker now too... :)

exact steps I did.

1. downgrade meteor meteor update --release 1.2.0.1
2. update meteor back to current meteor update --release 1.2.0.2
3. Perform a "Repair Disk Permissions" in "Disk Utility"
4. Rebooted into recover mode Reboot+"Cmd+R"
5. Selected my overall HD, and did "Repair Disk"
6. Did another "Repair Disk Permissions" for good measure...

Restarted... BOOM meter autorefresh, hot-loading or whatever, is wicked faster.

Went from 15-20 seconds for a trivial change, down to 1-2 seconds. Grease Lightning.

Node: this is for an app, no bigger than simple-todos

I want to go drink some :beer: now.

keep up good work guys. :+1:

edit:
fyi the bigger the app, the slower it gets... I definitely thinking about getting Solid-State drives...

[chrishowes]

Hey guys, just added the PR above that may help speed things up - would love your help w testing / feedback.

[bmustata]

+1

[shadowzick]

+1

[devgrok]

I'd recommend everyone who's having slow builds try setting the following environment variables
METEOR_DEBUG_BUILD=1
METEOR_PROFILE=1

It will tell give you the timings which should show the areas that are slow (verbose only shows messages on checking package versions not all the other steps so it gives the wrong impression of where the slow down occurs).

[coffenbacher]

@devgrok I'm getting ~15s reloads on the tutorial and arrived here. Here are the results with those settings for me: https://gist.github.com/coffenbacher/c15873390b9b604c792c

Edit: Using your patch speeds up reloads to about ~5s.

[coffenbacher]

I just rebuilt my environment on a VM on my local machine (instead of hosted VM) - still very slow. Way slower than I'm used to with something like React Hot Loader (based on Webpack).

Edit: and tried again on a $130 / month Azure VM with 7gb of RAM and two 3.3ghz Xeon E5-2673 v3 CPUs, SSD, Ubuntu 64-bit. The fastest reload I can get on the starter app (three files) is 10 seconds using the public Meteor.

Edit2: Giving up on Meteor again, this is too painful.

[quape]

It's probably because Meteor is doing some fractal rendering or SETI calculations in 14 of your 15 seconds.

[TankOs]

I'm experiencing the same issue on Arch Linux, 64 bit, AMD Phenom II X4 CPU, 4 GB RAM, HDD. Selecting the packages alone takes almost 4 seconds. Having to wait 6-10 seconds for every little change (HTML, JS) is indeed very very annoying.

Here's the profiling output: http://dpaste.com/0904JNE

Packages:

angular                         1.3.0
angularui:angular-ui-bootstrap  0.13.0
angularui:angular-ui-router     0.2.15
cfs:filesystem                  0.1.2
cfs:s3                          0.1.3
cfs:standard-packages           0.5.9
es5-shim                        4.1.14
flemay:less-autoprefixer        1.2.0
fortawesome:fontawesome         4.5.0
fourseven:scss                  3.4.1
insecure                        1.0.4
jquery                          1.11.4
meteor-base                     1.0.1
mobile-experience               1.0.1
mongo                           1.1.3
session                         1.1.1
standard-minifiers              1.0.2
stevezhu:lodash                 3.10.1
tracker                         1.0.9
twbs:bootstrap                  3.3.6

Anything else I can help with?

[ronhornbaker]

Same issue here, evaluating latest vanilla Meteor and your Local Market example app on a 2012 MacBook Air with SSD (fairly fast machine in all other aspects). Seeing about a 10s delay between saving a change in home.html and the server refreshing the browser. Very painful at 10, can't imagine waiting longer with a larger project.

Have also been evaluating React Native recently, where file changes result in nearly instant refreshes on a tethered iPhone and simulator (at same time). Apples to oranges, I know, but still – I want to bet the future on Meteor for mobile dev but slow build cycles may be enough to force me to pass.

[devgrok]

I found that when I had a completely clean checkout of the meteor source and using the smallest helloWorld project, the loadFromCatalog was quick.
As soon as I downloaded any packages (whether the project was using it or not) the speed slowed down considerably.
Didn't try it with the release version of meteor but I imagine it would be the same result (quick with empty local package cache, slow with packages cached).

Another tip - I had a modified version of a library downloaded (via bower) into my public folder.
This library (materialize) had a lot of source and compiled files and meteor was copying across (during a copy phase) the entire directory. Even with a SSD it was taking several seconds.
Turning this library into a package sped it up and also allowed me to select the files I actually wanted it to copy across.

I also ditched the package 'standard-minifiers' for the time being. Not sure if it should have been activating in development but if it is then removing it can at least cut another step out.

[NazarK]

having tendency to return back to RoR because of this, only good usage for meteor I see is building simple mobile apps with meteor.

[smothers]

Has the MDG team weighed in on this? Are they still working on issues?

[rclai]

They are working on this here.

[ORESoftware]

does anyone know how I can unfollow this thread?
On Dec 14, 2015 2:46 PM, "Ron Hornbaker" [email protected] wrote:

Same issue here, evaluating latest vanilla Meteor and your Local Market
example app on a 2012 MacBook Air with SSD (fairly fast machine in all
other aspects). Seeing about a 10s delay between saving a change in
home.html and the server refreshing the browser. Very painful at 10, can't
imagine waiting longer with a larger project.

Have also been evaluating React Native recently, where file changes result
in nearly instant refreshes on a tethered iPhone and simulator (at same
time). Apples to oranges, I know, but still – I want to bet the future on
Meteor for mobile dev but slow build cycles may be enough to force me to
pass.

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

[coffenbacher]

Click Unsubscribe on the upper right hand side of Github web UI https://help.github.com/articles/unsubscribing-from-conversations/

[aofrozen]

I found a solution to make meteor build faster by removing LESS, SASS, and reducing around 200 files to 7 files with Gulp and using RAM drive (optional). Gulp completed under 100ms to bundle all javascript & html files to 7 files and compile SASS & LESS to CSS.

Without gulp, meteorjs build completed around 15 seconds.

With gulp, meteorjs build completed around 4.2 seconds (select Package Versions: 3.1 seconds and total 1.1 seconds)

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

[quangv]

@aofrozen nice.

Care to share your Gulpfile? :smile:

[aofrozen]

If you have slow internet then it will slow your development due to meteor solver (select package versions) will try to connect packages site. Solution is stay internet offline while working on project that will be fast.

Gulpfile here:

var gulp = require('gulp');

var gutil = require('gulp-util'),
//jshint = require('gulp-jshint'),
//browserify = require('gulp-browserify'),
concat = require('gulp-concat'),
//minifyCss = require('gulp-minify-css'),
copy = require('gulp-copy'),
//plumber = require('gulp-plumber'),
//uglify = require('gulp-uglify'),
//sourcemaps = require('gulp-sourcemaps'),
//rename = require('gulp-rename'),
//source = require('vinyl-source-stream'),
watchify = require('watchify'),
//buffer = require('vinyl-buffer'),
fastbrowserify = require('browserify'),
assign = require('lodash.assign'),
//karma = require('gulp-karma'),
sass = require('gulp-sass');

/* METEOR OPTIMIZATION */

gulp.task('meteor', function(){
gulp.start('sass:watch', 'jsclient:watch', 'htmlclient:watch', 'libclient:watch', 'libclient:watch', 'lib:watch', 'jsserver:watch', 'collections:watch');
});

//ALL SASS FILES
gulp.task('sass:watch', function () {
gulp.start('sass');
gulp.watch(['sass/_.sass', 'client/__/_.sass'], ['sass']);
});

gulp.task('sass', function () {
gulp.src(['sass/_.sass', 'client/__/_.sass'])
.pipe(sass().on('error', sass.logError))
.pipe(concat('bundle.css'))
.pipe(gulp.dest('desktop/client/css'));
});

//CLIENT JS
gulp.task('jsclient:watch', function(){
gulp.start('jsclient');
gulp.watch('client/*_/_.js', ['jsclient']);
});

gulp.task('jsclient', function(){
console.log('client js is changed');
gulp.src(['client/*_/_.js'])
.pipe(concat('bundle.js'))
.pipe(gulp.dest('desktop/client/'));
});

//CLIENT HTML
gulp.task('htmlclient:watch', function(){
gulp.start('htmlclient');
gulp.watch('client/*_/_.html', ['htmlclient']);
});

gulp.task('htmlclient', function(){
console.log('html client is changed');
gulp.src(['client/*_/_.html'])
.pipe(concat('bundle.html'))
.pipe(gulp.dest('desktop/client/'));
});

//CLIENT LIB
gulp.task('libclient:watch', function(){
gulp.start('libclient');
gulp.watch('libclient/*.js', ['libclient']);
});

gulp.task('libclient', function(){
console.log('client lib client js is changed');
gulp.src(['libclient/*.js'])
.pipe(concat('lib-bundle.js'))
.pipe(gulp.dest('desktop/lib/client'));
});

//COLLECTION
gulp.task('collections:watch', function(){
gulp.start('collections');
gulp.watch(['lib/collections/*.js'], ['lib']);
});

gulp.task('collections', function(){
console.log('collection js is changed');
gulp.src(['lib/collections/*.js'])
.pipe(concat('collections.js'))
.pipe(gulp.dest('desktop/lib/collections'));
});

//LIBRARY FOR BOTH SERVER AND CLIENT
gulp.task('lib:watch', function(){
gulp.start('lib');
gulp.watch(['lib/*.js'], ['lib']);
});

gulp.task('lib', function(){
console.log('lib js is changed');
gulp.src(['lib/*.js'])
.pipe(concat('lib.js'))
.pipe(gulp.dest('desktop/lib'));
});

//SERVER
gulp.task('jsserver:watch', function(){
gulp.start('jsserver');
gulp.watch('server/*.js', ['jsserver']);
});

gulp.task('jsserver', function(){
console.log('server js is changed');
gulp.src(['server/*.js'])
.pipe(concat('bundle.js'))
.pipe(gulp.dest('desktop/server'));
});

[aofrozen]

@coffenbacher

I think your meteor project was slow because of your poor internet/connection.

[aofrozen]

I fixed meteorjs' solver performance by adding cache. I am not sure how to contribute meteorjs.

Meteor solver average was 3-4 seconds. Now it is 800ms to 1 second.

| Select Package Versions: 936.1
| new CS.Input: 2.5
| Input#loadFromCatalog (sqlite): 820.2
| other Select Package Versions: 113.5
|
| Input#loadFromCatalog (sqlite): 820.2
| other Select Package Versions: 113.5
| new CS.Input: 2.5
| Total: 936.1
|
| files.readFile: 125.1
| files.exists: 2.5
| Rebuild App: 1226.1
| compiler.compile(the app): 139.8
| Isopack#getUnibuildAtArch: 3.4
| files.readdir: 4.6
| files.stat: 18.0
| files.realpath: 4.4
| files.readFile: 28.0
| sha1: 50.7
| other compiler.compile(the app): 30.8
| Isopack#getUnibuildAtArch: 4.9
| bundler.bundle..makeClientTarget: 885.2
| Target#make: 885.1
| Isopack#getUnibuildAtArch: 37.9
| Target#_runCompilerPlugins: 220.8
| files.stat: 2.8
| Isopack#ensurePluginsInitialized: 1.0
| sha1: 19.6
| Isopack#getUnibuildAtArch: 21.9
| processing files with ecmascript (for target web.browser): 22.2
| other processing files with ecmascript (for target web.browser): 21.8
| processing files with templating (for target web.browser): 12.2
| sha1: 1.2
| other processing files with templating (for target web.browser): 10.9
| processing files with meteor (for target web.browser): 2.5
| processing files with ecmascript (for target web.cordova): 19.8
| other processing files with ecmascript (for target web.cordova): 19.2
| processing files with templating (for target web.cordova): 10.9
| sha1: 1.3
| other processing files with templating (for target web.cordova): 9.5
| processing files with meteor (for target web.cordova): 1.2
| other Target#_runCompilerPlugins: 104.3
| Target#_emitResources: 514.1
| PackageSourceBatch#getResources: 500.4
| PackageSourceBatch#_linkJS: 493.0
| sha1: 4.8
| files.readFile: 160.2
| Isopack#getUnibuildAtArch: 22.2
| other PackageSourceBatch#_linkJS: 305.7
| other PackageSourceBatch#getResources: 7.4
| other Target#_emitResources: 13.7
| sha1: 46.8
| other Target#make: 64.8
| bundler..writeTargetToPath: 187.9
| ClientTarget#write: 186.9
| Builder#write: 31.9
| Builder#_ensureDirectory: 2.3
| sha1: 19.9
| other Builder#write: 9.7
| bundler..writeFile: 16.3
| Builder#write: 12.7
| Builder#_ensureDirectory: 3.3
| other Builder#write: 9.4
| other bundler..writeFile: 3.7
| files.writeFile: 2.7
| other ClientTarget#write: 135.3
| other Rebuild App: 7.8
|
| files.readFile: 313.3
| other PackageSourceBatch#_linkJS: 305.7
| sha1: 145.6
| other ClientTarget#write: 135.3
| other Target#_runCompilerPlugins: 104.3
| Isopack#getUnibuildAtArch: 90.3
| other Target#make: 64.8
| other compiler.compile(the app): 30.8
| other processing files with ecmascript (for target web.browser): 21.8
| files.stat: 21.1
| other processing files with ecmascript (for target web.cordova): 19.2
| other Builder#write: 19.0
| other Target#_emitResources: 13.7
| other processing files with templating (for target web.browser): 10.9
| other processing files with templating (for target web.cordova): 9.5
| other Rebuild App: 7.8
| other PackageSourceBatch#getResources: 7.4
| Builder#_ensureDirectory: 5.6
| files.readdir: 4.6
| files.realpath: 4.4
| other bundler..writeFile: 3.7
| files.writeFile: 2.7
| files.exists: 2.7
| processing files with meteor (for target web.browser): 2.5
| processing files with meteor (for target web.cordova): 1.2
| Isopack#ensurePluginsInitialized: 1.1
| Total: 1349.0

[quape]

How can I switch to dev mode?

[ljack]

Meteor build time is starting to bother me really much, let's work a solution to reduce it significantly.

METEOR_PROFILE=1 meteor startup http://pastebin.com/C70FebST Total: 18473.6
METEOR_PROFILE=1 meteor single edit in single html http://pastebin.com/qxCv6cYp Total: 7212.3

Also startup with METEOR_DEBUG_BUILD=1 http://pastebin.com/y3pn0F4K startup and reload
http://pastebin.com/jCYZEnBr

The startup time I can live with but the refresh time is really getting on me ;)

[MichaelJCole]

I have a SSD with 500mb/s read, and Meteor spends 10 seconds querying sqlite for a 30 seconds build.

Downgrading/upgrading Meteor actually made it worse. I can't imagine anyone with a HDD using meteor for a non-tutorial-scale project.

Frustrated. Your gulp file should make me laugh, but it's not working. This seems to be a pretty long-standing issue. Looking forward to any kind of fix.

[ljack]

Actually I did debug this a bit and there seems to be couple of reasons why it's so slow. 1st meteor actually runs/scans multiple versions of meteor-tool package directories. If you could do strace meteor help 2> meteor-strace.out and put that in pastebin so we could verify if this also happens on your system.

For me a quick fix for reducing reload time (this release doesn't help with startup) was to use 1.2.2-faster-rebuilds.0. But it helps with sqlite query times and reloading.

And remove any additional (besides 1.1.11-faster-rebuild.0 ) symlinks in ~/.meteor/packages/meteor-tool/ to reduce the time just a little bit more. Unfortunately meteor always downloads some "stable" (currently seems to be 1.1.10 ) version of meteor-tools and re-installs it back ;( So don't bother actually removing the symlinks in ~/.meteor/packages/meteor-tool unless you do it everytime (in a script e.g.) when starting meteor.. (but it still helps to reduce the startup time ;)

Startup with symlinks removed: http://pastebin.com/4hJc83CU
| Total: 19516.4
Startup with symlinks present: http://pastebin.com/VCK33e0q
| Total: 144699.6

~/.meteor/packages/meteor-tool> ls
1.1.10@   1.1.11-modules.5@  1.1.12-modules.5@  1.1.9@

meteor update --release 1.2.2-faster-rebuilds.0

ls -l ~/.meteor/packages/meteor-tool/
# delete other versions of meteor-tool except 1.1.11-faster-rebuild.0
cd ~/.meteor/packages/meteor-tool/
~/.meteor/packages/meteor-tool/> rm 1.1.10
~/.meteor/packages/meteor-tool/> rm 1.1.11-modules.5
~/.meteor/packages/meteor-tool/> rm 1.1.12-modules.5
~/.meteor/packages/meteor-tool/> rm 1.1.9

# fix meteor symlink in ̃~/.meteor/  see 1) below
~/.meteor> ls -l
total 12
lrwxrwxrwx   1 ubuntu ubuntu   53 Jan 29 18:17 meteor -> packages/meteor-tool/1.1.10/mt-os.linux.x86_64/meteor
drwxr-xr-x   4 ubuntu ubuntu 4096 Dec  9 21:26 package-metadata/
drwxr-xr-x 290 ubuntu ubuntu 4096 Feb  1 01:45 packages/
drwxr-xr-x   2 ubuntu ubuntu 4096 Jan 19 18:41 releases/
~/.meteor> 
ln -sf packages/meteor-tool/1.1.11-faster-rebuild.0/mt-os.linux.x86_64/meteor meteor
 ~/.meteor> ls -l
total 16
lrwxrwxrwx   1 ubuntu ubuntu   70 Feb  2 05:27 meteor -> packages/meteor-tool/1.1.11-faster-rebuild.0/mt-os.linux.x86_64/meteor*

1) if the meteor symlink is broken in ~/.meteor/ you'll see this

'/home/ubuntu/.meteor' exists, but '/home/ubuntu/.meteor/meteor' is not executable.

Also .meteor/local/bundler-cache/linker-directory in your meteor app directory could have several hundred megabytes of files in it and sometimes it helps to clean it. You can safely remove the whole directory.

ljack1:~/workspace/PITPA/.meteor/local/bundler-cache/linker (meteor-1.2.1) $ pwd
/home/ubuntu/workspace/PITPA/.meteor/local/bundler-cache/linker
ljack1:~/workspace/PITPA/.meteor/local/bundler-cache/linker (meteor-1.2.1) $ du -sh
29M     .

But basically meteor is very slow to rebuild. But it just might be doing too much.

[MichaelJCole]

I looked into it a bit from the sqlite standpoint. #6137

[aofrozen]

I am not sure what kind of problems you have. It can be a slow connection,
meteor version, how many packages and files, and other factors.

On Mon, Feb 1, 2016 at 5:34 PM, Michael Cole [email protected]
wrote:

I have a SSD, and Meteor spends 10 seconds querying sqlite for a 30
seconds build http://pastebin.com/wwDtYpxk.

Downgrading/upgrading Meteor actually made it worse.

Frustrated. Your gulp file should make me laugh, but it's not working.
This seems to be a pretty long-standing issue. Looking forward to any kind
of fix.

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

[bryaan]

meteor update --release [email protected]

From 6-10s to 1-2s.

:thumbsup:

[lnmunhoz]

@MichaelJCole I just tested the [email protected] release and the rebuild now is so much better!

[ljack]

Meteor 1.3-modules-beta.8 rocks!! Can't avoid giving my +1 ;)

[MichaelJCole]

@lnmunhoz Awesome! <3 it!

[chbiel]

the problem still exists for me.
when i use npm and meteor packages side by side and local packages i have a "check for ..."-time of 5-10 seconds plus build time for the platforms

[steve-ross]

I think i spend half my day waiting for meteor to refresh, we don't have the luxury of just jumping to a new dev build. I actually enjoyed working on another app the other day that was using livereload & grunt refresh happened so fast I didn't even see it.

[allpratik]

This is problem with me as well... takes forever to refresh.

[steve-ross]

Running meteor update --release 1.2.2-faster-rebuilds.0 on my project did help but, annoying to have to stash meteor versions every time i want to commit code to our repo.

Any changes to server side javascript is still slow though.

[bryaan]

Same experience with modding js code. Hopefully this is a priority for the
devs. Depending on your coding style these few seconds can really add up.

Sure you have the option to not refresh often and just bang out the code,
but that brings us to the second major problem. Where are the error
messages? Meteor fails quietly. Not good.

I noticed the dev version can cause quite a few problems with probject
libs. I'm in the business of getting things done, and these problems did
not have trivial solutions, so I had no choice but to revert.

I'll buy a beer for the dev who solves this :)

On Wednesday, March 2, 2016, Steve Ross [email protected] wrote:

Running meteor update --release 1.2.2-faster-rebuilds.0 on my project did
help but, annoying to have to stash meteor versions every time i want to
create a build.

Any changes to server side javascript is still slow though.

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

[steve-ross]

yeah agreed, I'll chip in a whole case of beer =)

probably spend at least 1/2 hour a day waiting for re-loads @30secs +

[aunz]

My 2 cents.
I recently updated from 1.2.1 to 1.3 and notice that rebuild time has become slower and that it takes longer for the client browser to refresh.
On Windows 10 x64, 8GB ram, i5 2.8 GHz

The profile output below is from a bare minimum app, it takes >4 seconds to rebuild. It appears that files.lstat takes up most of the time. In comparison, in 1.2.1, it took less than a second on my computer.

refreshing (x5)| (#13) Profiling: ProjectContext prepareProjectForBuild
|
| ProjectContext prepareProjectForBuild...........................150 ms (1)
| ├─ _initializeCatalog............................................31 ms (1)
| │  ├─ files.readFile                                             10 ms (27)
| │  ├─ files.exists                                                3 ms (15)
| │  ├─ runJavaScript package.js                                    1 ms (15)
| │  └─ other _initializeCatalog                                   15 ms
| ├─ _resolveConstraints...........................................72 ms (1)
| │  ├─ Select Package Versions....................................68 ms (1)
| │  │  ├─ new CS.Input                                             3 ms (1)
| │  │  └─ other Select Package Versions                           65 ms
| │  └─ other _resolveConstraints                                   4 ms
| ├─ _downloadMissingPackages......................................44 ms (1)
| │  ├─ Isopack.readMetadataFromDirectory..........................26 ms (60)
| │  │  ├─ files.exists                                             8 ms (60)
| │  │  ├─ files.readFile                                          14 ms (60)
| │  │  └─ other Isopack.readMetadataFromDirectory                  4 ms
| │  └─ other _downloadMissingPackages                             18 ms
| └─ _buildLocalPackages............................................3 ms (1)
|    ├─ IsopackCache Load local isopack.............................2 ms (60)
|    │  └─ Isopack#getStrongOrderedUsedAndImpliedPackages           1 ms (60)
|    └─ other _buildLocalPackages                                   1 ms
|
| Top leaves:
|
| (#13) Total: 150 ms (ProjectContext prepareProjectForBuild)
|
| (#14) Profiling: Rebuild App
|
| files.readFile                                                    3 ms (2)
| files.exists                                                      1 ms (3)
| files.writeFileAtomically........................................23 ms (1)
| └─ files.writeFile                                               22 ms (1)
| Rebuild App...................................................4,107 ms (1)
| ├─ compiler.compile(the app)..................................3,260 ms (1)
| │  └─ compileUnibuild (the app)...............................3,260 ms (2)
| │     ├─ files.readdir                                          282 ms (1340)
| │     ├─ files.stat                                               5 ms (70)
| │     ├─ files.realpath                                           5 ms (8)
| │     ├─ files.readFile                                           2 ms (9)
| │     ├─ files.lstat                                          2,306 ms (13062)
| │     ├─ files.exists                                            49 ms (354)
| │     └─ other compileUnibuild (the app)                        611 ms
| ├─ compiler.lint(the app)                                         2 ms (1)
| ├─ bundler.bundle..makeClientTarget.............................738 ms (1)
| │  └─ Target#make...............................................738 ms (1)
| │     ├─ Isopack#getUnibuildAtArch                                6 ms (341)
| │     ├─ Target#_runCompilerPlugins.............................196 ms (1)
| │     │  ├─ files.realpath                                       49 ms (37)
| │     │  ├─ sha1                                                  4 ms (138)
| │     │  ├─ Isopack#getUnibuildAtArch                             6 ms (335)
| │     │  ├─ plugin ecmascript...................................103 ms (1)
| │     │  │  ├─ Babel.compile                                     70 ms (36)
| │     │  │  ├─ sha1                                               1 ms (36)
| │     │  │  └─ other plugin ecmascript                           31 ms
| │     │  └─ other Target#_runCompilerPlugins                     33 ms
| │     ├─ Target#_emitResources..................................512 ms (1)
| │     │  ├─ PackageSourceBatch.computeJsOutputFilesMap..........493 ms (1)
| │     │  │  ├─ ImportScanner#_getInstallPath                     72 ms (338)
| │     │  │  ├─ ImportScanner#_findImportedModuleIdentifiers       5 ms (313)
| │     │  │  ├─ ImportScanner#_tryToResolveImportedPath..........216 ms (864)
| │     │  │  │  ├─ files.stat                                    114 ms (1126)
| │     │  │  │  ├─ ImportScanner#_resolvePkgJsonMain..............10 ms (12)
| │     │  │  │  │  ├─ ImportScanner#_readFile......................4 ms (10)
| │     │  │  │  │  │  └─ files.readFile                            4 ms (10)
| │     │  │  │  │  ├─ ImportScanner#_getInstallPath                1 ms (9)
| │     │  │  │  │  └─ other ImportScanner#_resolvePkgJsonMain      3 ms
| │     │  │  │  └─ other ImportScanner#_tryToResolveImportedPath  92 ms
| │     │  │  ├─ ImportScanner#_readFile..........................132 ms (286)
| │     │  │  │  ├─ files.readFile                                119 ms (286)
| │     │  │  │  ├─ sha1                                            5 ms (286)
| │     │  │  │  └─ other ImportScanner#_readFile                   8 ms
| │     │  │  └─ other PackageSourceBatch.computeJsOutputFilesMap  69 ms
| │     │  ├─ PackageSourceBatch#getResources......................17 ms (38)
| │     │  │  └─ PackageSourceBatch#_linkJS........................16 ms (38)
| │     │  │     ├─ linker.fullLink.................................6 ms (1)
| │     │  │     │  └─ linker Module#getPrelinkedFiles..............6 ms (1)
| │     │  │     │     ├─ linker File#getPrelinkedOutput            2 ms (5)
| │     │  │     │     └─ getPrelinkedFiles toStringWithSourceMap   4 ms (1)
| │     │  │     └─ other PackageSourceBatch#_linkJS                9 ms
| │     │  └─ other Target#_emitResources                           2 ms
| │     ├─ Target#minifyJs                                          4 ms (1)
| │     ├─ sha1                                                    16 ms (40)
| │     └─ other Target#make                                        5 ms
| ├─ bundler writeTargetToPath....................................105 ms (1)
| │  ├─ ClientTarget#write.........................................82 ms (1)
| │  │  ├─ files.mkdir                                              1 ms (3)
| │  │  ├─ bundler writeFile.......................................63 ms (40)
| │  │  │  └─ Builder#write........................................62 ms (40)
| │  │  │     ├─ Builder#_ensureDirectory                           1 ms (40)
| │  │  │     ├─ files.writeFile                                   30 ms (40)
| │  │  │     ├─ files.rename                                      26 ms (40)
| │  │  │     └─ other Builder#write                                5 ms
| │  │  ├─ Builder#write...........................................11 ms (7)
| │  │  │  ├─ files.writeFile                                       6 ms (7)
| │  │  │  └─ files.rename                                          5 ms (7)
| │  │  └─ other ClientTarget#write                                 5 ms
| │  └─ Builder#complete...........................................21 ms (1)
| │     └─ files.renameDirAlmostAtomically.........................21 ms (1)
| │        ├─ files.rename                                          1 ms (2)
| │        └─ files.rm_recursive                                   20 ms (1)
| └─ other Rebuild App                                              2 ms
|
| Top leaves:
| files.lstat..............................................2,306 ms (13062)
| other compileUnibuild (the app)............................611 ms (2)
| files.readdir..............................................282 ms (1340)
| files.readFile.............................................128 ms (308)
| files.stat.................................................121 ms (1207)
|
| (#14) Total: 4,134 ms (Rebuild App)
|
=> Client modified -- refreshing (x6)

[snajjar]

+1, Meteor build is slower on 1.3 (causing some deployment scripts to fail)

[richard-edwards]

My build times are terrible as well. I'm on Windows 10 x64, i7 with 32GB RAM and project is on a SSD.

Big culprit is files.lstat with 16,211 ms on Windows 10 machine

Total Rebuild by removing an empty line on a jsx file:

Windows - 28,098 ms
Mac Mini - 2,745 ms

Here is the top ones for the Windows machine:

Top leaves:                                                               
files.lstat.............................................15,883 ms (133434)
other compileUnibuild (the app)..........................5,062 ms (2)     
files.writeFile..........................................2,382 ms (236)   
files.readdir............................................1,926 ms (11357) 
files.stat.................................................436 ms (5038)  
files.readFile.............................................286 ms (1088)  
other ImportScanner#_tryToResolveImportedPath..............271 ms (2317)  
other PackageSourceBatch.computeJsOutputFilesMap...........221 ms (1)     
files.rm_recursive.........................................193 ms (2)     
CssTools.parseCss..........................................193 ms (9)     
files.rename...............................................173 ms (238)   
Babel.compile..............................................172 ms (151)   
ImportScanner#_getInstallPath..............................160 ms (977)   
CssTools.stringifyCss......................................152 ms (1)     

[s7dhansh]

For me its Babel.compile (Meteor 1.2 used to give me 1s reload time, 1.3 gives 7s)

Top leaves:
| Babel.compile............................................2,759 ms (290)
| files.readFile...........................................1,818 ms (8855)
| other compileUnibuild (the app)............................585 ms (2)
| other ClientTarget#write...................................318 ms (1)
| sha1.......................................................273 ms (10530)

[patrickml]

Meteor 1.3 Full Build Time Report -- Most definitely slower

The 89 seconds at the bottom is concerning...

 START CAPTURE 0 undefined took NaN
| (#1) Profiling: ProjectContext prepareProjectForBuild
   START 1 preparing project
     START 2 reading project metadata
     DONE 2 reading project metadata took 9
     START CAPTURE 2 undefined took NaN
       START 3 scanning local packages
         START 4 looking for packages
         DONE 4 looking for packages took 12
         START 4 initializing packages
         DONE 4 initializing packages took 0
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/collections`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/collections`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/collections` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/collections` took 8
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/core`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/core`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/core` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/core` took 5
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/mail-parser`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/mail-parser`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/mail-parser` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/flex-2/packages/mail-parser` took 4
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/accounting`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/accounting`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/accounting` took 4
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/accounting` took 7
         START 4 initializing packages child
         DONE 4 initializing packages child took 3
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/admob`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/admob`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/admob` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/admob` took 9
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/braintree`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/braintree`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/braintree` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/braintree` took 4
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/collection-methods`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/collection-methods`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/collection-methods` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/collection-methods` took 3
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/comments`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/comments`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/comments` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/comments` took 3
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/core`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/core`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/core` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/core` took 5
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/errors-to-github-issue`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/errors-to-github-issue`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/errors-to-github-issue` took 4
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/errors-to-github-issue` took 22
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-email`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-email`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-email` took 5
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-email` took 11
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-lib`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-lib`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-lib` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-lib` took 5
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-theme`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-theme`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-theme` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/flex-theme` took 6
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/floatlabels`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/floatlabels`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/floatlabels` took 5
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/floatlabels` took 9
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/http-status`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/http-status`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/http-status` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/http-status` took 8
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-braintree`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-braintree`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-braintree` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-braintree` took 3
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-mongo-algolia-sync`
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-mongo-algolia-sync` took 2
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-publish-composite`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-publish-composite`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-publish-composite` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-publish-composite` took 3
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-stripe-sync`
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-stripe-sync` took 2
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-transitioner`
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/meteor-transitioner` took 3
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/osmosis`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/osmosis`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/osmosis` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/osmosis` took 6
         START 4 initializing packages child
         DONE 4 initializing packages child took 3
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-layouts`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-layouts`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-layouts` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-layouts` took 7
         START 4 initializing packages child
         DONE 4 initializing packages child took 2
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-mediumeditor`
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-mediumeditor` took 8
         START 4 initializing packages child
         DONE 4 initializing packages child took 2
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-modal`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-modal`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-modal` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-modal` took 5
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-quill`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-quill`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-quill` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/react-quill` took 4
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/sideburns`
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/sideburns` took 2
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/singularity`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/singularity`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/singularity` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/singularity` took 4
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/swal`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/swal`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/swal` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/swal` took 4
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/taxjar`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/taxjar`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/taxjar` took 2
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/taxjar` took 3
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-form`
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-form` took 2
         START 4 initializing packages child
         DONE 4 initializing packages child took 0
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-password`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-password`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-password` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-password` took 5
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-phone`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-phone`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-phone` took 4
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/validate-phone` took 10
         START 4 initializing packages child
         DONE 4 initializing packages child took 1
         START 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/wormhole`
           START 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/wormhole`
           DONE 5 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/wormhole` took 1
         DONE 4 reading package from `/Users/patricklewis/Documents/sites/meteor/packages/wormhole` took 4
       DONE 3 scanning local packages took 242
     END CAPTURE 2 undefined took 244
     START CAPTURE 2 undefined took NaN
       START 3 selecting package versions
         START CAPTURE 4 loading isopacket `constraint-solver` took NaN
         END CAPTURE 4 loading isopacket `constraint-solver` took 66
       DONE 3 selecting package versions took 4520
     END CAPTURE 2 undefined took 4520
     START CAPTURE 2 undefined took NaN
       START 3 downloading missing packages
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 11
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for acemtp:[email protected]
         DONE 4 checking for acemtp:[email protected] took 2
         START 4 checking for alanning:[email protected]
         DONE 4 checking for alanning:[email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for cosmos:[email protected]
         DONE 4 checking for cosmos:[email protected] took 3
         START 4 checking for dburles:[email protected]
         DONE 4 checking for dburles:[email protected] took 3
         START 4 checking for dburles:[email protected]
         DONE 4 checking for dburles:[email protected] took 3
         START 4 checking for dburles:[email protected]
         DONE 4 checking for dburles:[email protected] took 5
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for drewy:[email protected]
         DONE 4 checking for drewy:[email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for edgee:[email protected]
         DONE 4 checking for edgee:[email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for eluck:[email protected]
         DONE 4 checking for eluck:[email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 4
         START 4 checking for fourseven:[email protected]
         DONE 4 checking for fourseven:[email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for jeremy:[email protected]_12
         DONE 4 checking for jeremy:[email protected]_12 took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for kadira:[email protected]
         DONE 4 checking for kadira:[email protected] took 4
         START 4 checking for kadira:[email protected]
         DONE 4 checking for kadira:[email protected] took 11
         START 4 checking for lai:[email protected]_1
         DONE 4 checking for lai:[email protected]_1 took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for matb33:[email protected]
         DONE 4 checking for matb33:[email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for meteorhacks:[email protected]
         DONE 4 checking for meteorhacks:[email protected] took 2
         START 4 checking for meteorhacks:[email protected]
         DONE 4 checking for meteorhacks:[email protected] took 2
         START 4 checking for meteorhacks:[email protected]
         DONE 4 checking for meteorhacks:[email protected] took 2
         START 4 checking for meteorhacks:[email protected]
         DONE 4 checking for meteorhacks:[email protected] took 3
         START 4 checking for meteorhacks:[email protected]
         DONE 4 checking for meteorhacks:[email protected] took 2
         START 4 checking for meteorhacks:[email protected]
         DONE 4 checking for meteorhacks:[email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 7
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 5
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for momentjs:[email protected]
         DONE 4 checking for momentjs:[email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]_2
         DONE 4 checking for [email protected]_2 took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 4
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 5
         START 4 checking for pcel:[email protected]
         DONE 4 checking for pcel:[email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 5
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 5
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 5
         START 4 checking for risul:[email protected]
         DONE 4 checking for risul:[email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for seba:[email protected]
         DONE 4 checking for seba:[email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 5
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 4
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 5
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for tmeasday:[email protected]
         DONE 4 checking for tmeasday:[email protected] took 1
         START 4 checking for tmeasday:[email protected]
         DONE 4 checking for tmeasday:[email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 3
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 1
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for [email protected]
         DONE 4 checking for [email protected] took 2
         START 4 checking for wylio:[email protected]
         DONE 4 checking for wylio:[email protected] took 2
         START 4 checking for zimme:[email protected]
         DONE 4 checking for zimme:[email protected] took 1
         START 4 checking for zimme:[email protected]
         DONE 4 checking for zimme:[email protected] took 1
       DONE 3 downloading missing packages took 328
     END CAPTURE 2 undefined took 328
     START 2 building local packages
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 38
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 33
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 7
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 10
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 10
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 9
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 9
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 22
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 8
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 10
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 11
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 28
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 8
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 14
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 22
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 10
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 9
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 16
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 21
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 11
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 8
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 29
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 11
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 53
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]_2
       DONE 3 loading package [email protected]_2 took 7
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 9
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 8
       START 3 loading package acemtp:[email protected]
       DONE 3 loading package acemtp:[email protected] took 10
       START 3 loading package alanning:[email protected]
       DONE 3 loading package alanning:[email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 25
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 20
       START 3 loading package cosmos:[email protected]
       DONE 3 loading package cosmos:[email protected] took 34
       START 3 loading package dburles:[email protected]
       DONE 3 loading package dburles:[email protected] took 4
       START 3 loading package dburles:[email protected]
       DONE 3 loading package dburles:[email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 40
       START 3 loading package dburles:[email protected]
       DONE 3 loading package dburles:[email protected] took 4
       START 3 loading package lai:[email protected]_1
       DONE 3 loading package lai:[email protected]_1 took 13
       START 3 loading package drewy:[email protected]
       DONE 3 loading package drewy:[email protected] took 11
       START 3 loading package momentjs:[email protected]
       DONE 3 loading package momentjs:[email protected] took 8
       START 3 loading package edgee:[email protected]
       DONE 3 loading package edgee:[email protected] took 9
       START 3 loading package eluck:[email protected]
       DONE 3 loading package eluck:[email protected] took 3
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 13
       START 3 preparing to build package flex:core
         START 4 building package flex:core
         DONE 4 building package flex:core took 19
       DONE 3 preparing to build package flex:core took 20
       START 3 preparing to build package flex:mail-parser
         START 4 building package flex:mail-parser
         DONE 4 building package flex:mail-parser took 16
       DONE 3 preparing to build package flex:mail-parser took 17
       START 3 loading package fourseven:[email protected]
       DONE 3 loading package fourseven:[email protected] took 21
       START 3 preparing to build package gwendall:mongo-algolia-sync
         START 4 loading package matb33:[email protected]
         DONE 4 loading package matb33:[email protected] took 17
         START 4 building package gwendall:mongo-algolia-sync
         DONE 4 building package gwendall:mongo-algolia-sync took 6
       DONE 3 preparing to build package gwendall:mongo-algolia-sync took 23
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 5
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 10
       START 3 loading package jeremy:[email protected]_12
       DONE 3 loading package jeremy:[email protected]_12 took 4
       START 3 loading package kadira:[email protected]
       DONE 3 loading package kadira:[email protected] took 7
       START 3 loading package kadira:[email protected]
       DONE 3 loading package kadira:[email protected] took 29
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 12
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 2
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 loading package meteorhacks:[email protected]
       DONE 3 loading package meteorhacks:[email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 2
       START 3 loading package meteorhacks:[email protected]
       DONE 3 loading package meteorhacks:[email protected] took 5
       START 3 loading package meteorhacks:[email protected]
       DONE 3 loading package meteorhacks:[email protected] took 40
       START 3 loading package meteorhacks:[email protected]
       DONE 3 loading package meteorhacks:[email protected] took 5
       START 3 loading package meteorhacks:[email protected]
       DONE 3 loading package meteorhacks:[email protected] took 5
       START 3 loading package meteorhacks:[email protected]
       DONE 3 loading package meteorhacks:[email protected] took 6
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 4
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 2
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 preparing to build package patrickml:collection-methods
         START 4 building package patrickml:collection-methods
         DONE 4 building package patrickml:collection-methods took 17
       DONE 3 preparing to build package patrickml:collection-methods took 17
       START 3 preparing to build package patrickml:react-layouts
         START 4 loading package [email protected]
         DONE 4 loading package [email protected] took 5
         START 4 loading package [email protected]
         DONE 4 loading package [email protected] took 9
         START 4 loading package tmeasday:[email protected]
         DONE 4 loading package tmeasday:[email protected] took 11
         START 4 loading package [email protected]
         DONE 4 loading package [email protected] took 11
         START 4 building package patrickml:react-layouts
         DONE 4 building package patrickml:react-layouts took 14
       DONE 3 preparing to build package patrickml:react-layouts took 52
       START 3 preparing to build package patrickml:react-modal
         START 4 building package patrickml:react-modal
         DONE 4 building package patrickml:react-modal took 34
       DONE 3 preparing to build package patrickml:react-modal took 35
       START 3 preparing to build package patrickml:react-quill
         START 4 building package patrickml:react-quill
         DONE 4 building package patrickml:react-quill took 12
       DONE 3 preparing to build package patrickml:react-quill took 12
       START 3 preparing to build package patrickml:singularity
         START 4 building package patrickml:singularity
         DONE 4 building package patrickml:singularity took 47
       DONE 3 preparing to build package patrickml:singularity took 47
       START 3 preparing to build package patrickml:wormhole
         START 4 building package patrickml:wormhole
         DONE 4 building package patrickml:wormhole took 24
       DONE 3 preparing to build package patrickml:wormhole took 25
       START 3 loading package pcel:[email protected]
       DONE 3 loading package pcel:[email protected] took 9
       START 3 loading package risul:[email protected]
       DONE 3 loading package risul:[email protected] took 7
       START 3 loading package seba:[email protected]
       DONE 3 loading package seba:[email protected] took 25
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 7
       START 3 loading package [email protected]
       DONE 3 loading package [email protected] took 3
       START 3 preparing to build package skinnygeek1010:validate-form
         START 4 building package skinnygeek1010:validate-form
         DONE 4 building package skinnygeek1010:validate-form took 13
       DONE 3 preparing to build package skinnygeek1010:validate-form took 14
       START 3 loading package tmeasday:[email protected]
       DONE 3 loading package tmeasday:[email protected] took 6
       START 3 loading package wylio:[email protected]
       DONE 3 loading package wylio:[email protected] took 5
       START 3 loading package zimme:[email protected]
       DONE 3 loading package zimme:[email protected] took 7
       START 3 loading package zimme:[email protected]
       DONE 3 loading package zimme:[email protected] took 12
     DONE 2 building local packages took 1394
   DONE 1 preparing project took 6507
| 
| ProjectContext prepareProjectForBuild.........................6,507 ms (1)
| ├─ _readProjectMetadata...........................................9 ms (1)
| │  ├─ files.readFile                                              1 ms (6)
| │  └─ other _readProjectMetadata                                  8 ms
| ├─ _initializeCatalog...........................................244 ms (1)
| │  ├─ files.readFile                                             26 ms (94)
| │  ├─ sha1                                                        2 ms (93)
| │  ├─ files.exists                                               25 ms (60)
| │  ├─ runJavaScript package.js                                   16 ms (60)
| │  ├─ sqlite query                                               16 ms (31)
| │  └─ other _initializeCatalog                                  159 ms
| ├─ _resolveConstraints........................................4,528 ms (1)
| │  ├─ bundler.readJsImage........................................10 ms (1)
| │  │  ├─ files.readFile                                           8 ms (10)
| │  │  └─ other bundler.readJsImage                                2 ms
| │  ├─ JsImage#load...............................................65 ms (1)
| │  │  ├─ runJavaScript packages/underscore.js                     7 ms (1)
| │  │  ├─ runJavaScript packages/meteor.js                        10 ms (1)
| │  │  ├─ runJavaScript packages/check.js                          1 ms (1)
| │  │  ├─ runJavaScript packages/package-version-parser.js         3 ms (1)
| │  │  ├─ runJavaScript packages/logic-solver.js                  38 ms (1)
| │  │  ├─ runJavaScript packages/constraint-solver.js              3 ms (1)
| │  │  └─ other JsImage#load                                       2 ms
| │  ├─ Select Package Versions.................................4,440 ms (1)
| │  │  ├─ new CS.Input                                             9 ms (1)
| │  │  ├─ Input#loadOnlyPreviousSolution..........................90 ms (1)
| │  │  │  ├─ sqlite query                                         48 ms (111)
| │  │  │  └─ other Input#loadOnlyPreviousSolution                 42 ms
| │  │  ├─ Input#loadFromCatalog................................3,109 ms (1)
| │  │  │  ├─ sqlite query                                        328 ms (262)
| │  │  │  └─ other Input#loadFromCatalog                       2,782 ms
| │  │  ├─ new CS.Solver...........................................45 ms (1)
| │  │  │  └─ Solver#analyze.......................................45 ms (1)
| │  │  │     ├─ analyze allowed versions                          16 ms (1)
| │  │  │     ├─ analyze reachability                               5 ms (1)
| │  │  │     └─ analyze constraints                               22 ms (1)
| │  │  └─ Solver#getAnswer.....................................1,185 ms (1)
| │  │     ├─ new Logic.Solver (MiniSat start-up)                  13 ms (1)
| │  │     ├─ generate package variables                          183 ms (1)
| │  │     ├─ generate dependency requirements                     95 ms (1)
| │  │     ├─ generate constraints                                212 ms (1)
| │  │     ├─ pre-solve                                           243 ms (1)
| │  │     ├─ minimize conflicts                                  185 ms (1)
| │  │     ├─ minimize unanticipated_prereleases                   50 ms (1)
| │  │     ├─ calculate previous_root distance costs                6 ms (1)
| │  │     ├─ minimize previous_root_incompat                      18 ms (1)
| │  │     ├─ minimize previous_root_major                          1 ms (1)
| │  │     ├─ minimize previous_root_minor                         10 ms (1)
| │  │     ├─ minimize previous_root_patch                          4 ms (1)
| │  │     ├─ calculate previous_indirect distance costs            4 ms (1)
| │  │     ├─ minimize previous_indirect_incompat                  12 ms (1)
| │  │     ├─ minimize previous_indirect_minor                      2 ms (1)
| │  │     ├─ minimize previous_indirect_patch                      4 ms (1)
| │  │     ├─ minimize previous_indirect_rest                       1 ms (1)
| │  │     ├─ lock down important versions                          5 ms (1)
| │  │     ├─ minimize new_indirect_minor                           5 ms (1)
| │  │     ├─ minimize total_packages                             121 ms (1)
| │  │     └─ other Solver#getAnswer                                3 ms
| │  └─ other _resolveConstraints                                  12 ms
| ├─ _downloadMissingPackages.....................................329 ms (1)
| │  ├─ Isopack.readMetadataFromDirectory.........................229 ms (111)
| │  │  ├─ files.exists                                           136 ms (111)
| │  │  ├─ files.readFile                                          71 ms (111)
| │  │  └─ other Isopack.readMetadataFromDirectory                 21 ms
| │  └─ other _downloadMissingPackages                            100 ms
| ├─ _buildLocalPackages........................................1,395 ms (1)
| │  ├─ IsopackCache Load local isopack.........................1,175 ms (111)
| │  │  ├─ files.stat                                              12 ms (111)
| │  │  ├─ Isopack#initFromPath.................................1,074 ms (111)
| │  │  │  ├─ files.realpath                                       85 ms (111)
| │  │  │  ├─ Isopack.readMetadataFromDirectory....................44 ms (111)
| │  │  │  │  ├─ files.exists                                       9 ms (111)
| │  │  │  │  ├─ files.readFile                                    25 ms (111)
| │  │  │  │  └─ other Isopack.readMetadataFromDirectory            9 ms
| │  │  │  ├─ files.readFile                                      176 ms (353)
| │  │  │  ├─ files.open                                          140 ms (839)
| │  │  │  ├─ files.read                                          307 ms (839)
| │  │  │  ├─ files.close                                          54 ms (839)
| │  │  │  ├─ bundler.readJsImage.................................121 ms (7)
| │  │  │  │  ├─ files.readFile                                   106 ms (119)
| │  │  │  │  └─ other bundler.readJsImage                         15 ms
| │  │  │  └─ other Isopack#initFromPath                          147 ms
| │  │  ├─ Isopack#getStrongOrderedUsedAndImpliedPackages           8 ms (111)
| │  │  └─ other IsopackCache Load local isopack                   81 ms
| │  ├─ IsopackCache Build local isopack..........................203 ms (10)
| │  │  ├─ files.readFile                                           6 ms (10)
| │  │  ├─ watch.isUpToDate........................................81 ms (10)
| │  │  │  ├─ files.readFile                                       19 ms (67)
| │  │  │  ├─ sha1                                                  2 ms (67)
| │  │  │  ├─ files.readdir                                        25 ms (108)
| │  │  │  ├─ files.stat                                           14 ms (544)
| │  │  │  └─ other watch.isUpToDate                               20 ms
| │  │  ├─ files.stat                                               2 ms (10)
| │  │  ├─ Isopack#initFromPath....................................97 ms (10)
| │  │  │  ├─ files.realpath                                        6 ms (10)
| │  │  │  ├─ Isopack.readMetadataFromDirectory....................10 ms (10)
| │  │  │  │  ├─ files.exists                                       3 ms (10)
| │  │  │  │  ├─ files.readFile                                     5 ms (10)
| │  │  │  │  └─ other Isopack.readMetadataFromDirectory            1 ms
| │  │  │  ├─ files.readFile                                       11 ms (20)
| │  │  │  ├─ files.open                                           15 ms (95)
| │  │  │  ├─ files.read                                           35 ms (95)
| │  │  │  ├─ files.close                                           6 ms (95)
| │  │  │  └─ other Isopack#initFromPath                           14 ms
| │  │  ├─ Isopack#getMergedWatchSet                                1 ms (10)
| │  │  └─ other IsopackCache Build local isopack                  16 ms
| │  └─ other _buildLocalPackages                                  16 ms
| └─ other ProjectContext prepareProjectForBuild                    1 ms
| 
| Top leaves:
| other Input#loadFromCatalog..............................2,782 ms (1)
| files.readFile.............................................455 ms (911)
| sqlite query...............................................391 ms (404)
| files.read.................................................342 ms (934)
| pre-solve..................................................243 ms (1)
| generate constraints.......................................212 ms (1)
| minimize conflicts.........................................185 ms (1)
| generate package variables.................................183 ms (1)
| files.exists...............................................174 ms (300)
| other Isopack#initFromPath.................................161 ms (121)
| other _initializeCatalog...................................159 ms (1)
| files.open.................................................154 ms (934)
| minimize total_packages....................................121 ms (1)
| 
| (#1) Total: 6,507 ms (ProjectContext prepareProjectForBuild)
| 
 END CAPTURE 0 undefined took 6529
 START CAPTURE 0 building the application took NaN
   START 1 determining active plugins
     START 2 loading plugin `compile-ecmascript` from package `ecmascript`
 START CAPTURE 0 loading isopacket `ddp` took NaN
 END CAPTURE 0 loading isopacket `ddp` took 286
     DONE 2 loading plugin `compile-ecmascript` from package `ecmascript` took 390
     START 2 running registerCompiler callback in package ecmascript
     DONE 2 running registerCompiler callback in package ecmascript took 9
     START 2 loading plugin `compileScssBatch` from package `fourseven:scss`
     DONE 2 loading plugin `compileScssBatch` from package `fourseven:scss` took 443
     START 2 running registerCompiler callback in package fourseven:scss
     DONE 2 running registerCompiler callback in package fourseven:scss took 1
     START 2 loading plugin `minifyStd` from package `seba:minifiers-autoprefixer`
     DONE 2 loading plugin `minifyStd` from package `seba:minifiers-autoprefixer` took 829
     START 2 running registerMinifier callback in package seba:minifiers-autoprefixer
     DONE 2 running registerMinifier callback in package seba:minifiers-autoprefixer took 1
     START 2 running registerMinifier callback in package seba:minifiers-autoprefixer
     DONE 2 running registerMinifier callback in package seba:minifiers-autoprefixer took 1
     START 2 loading plugin `basicFileTypes` from package `meteor`
     DONE 2 loading plugin `basicFileTypes` from package `meteor` took 0
     START 2 running registerCompiler callback in package meteor
     DONE 2 running registerCompiler callback in package meteor took 1
   DONE 1 determining active plugins took 1676
   START 1 determining active plugins
   DONE 1 determining active plugins took 0
   START 1 building for web.browser
     START 2 linking the program
     DONE 2 linking the program took 20
     START 2 loading plugin `compileTemplatesBatch` from package `templating`
     DONE 2 loading plugin `compileTemplatesBatch` from package `templating` took 507
     START 2 running registerCompiler callback in package templating
     DONE 2 running registerCompiler callback in package templating took 1
     START 2 loading plugin `compileCoffeescript` from package `coffeescript`
     DONE 2 loading plugin `compileCoffeescript` from package `coffeescript` took 452
     START 2 running registerCompiler callback in package coffeescript
     DONE 2 running registerCompiler callback in package coffeescript took 1
     START 2 loading plugin `CosmosBrowserify` from package `cosmos:browserify`
     DONE 2 loading plugin `CosmosBrowserify` from package `cosmos:browserify` took 839
     START 2 running registerCompiler callback in package cosmos:browserify
     DONE 2 running registerCompiler callback in package cosmos:browserify took 1
     START 2 processing files with ecmascript (for target web.browser)
     DONE 2 processing files with ecmascript (for target web.browser) took 2632
     START 2 processing files with templating (for target web.browser)
     DONE 2 processing files with templating (for target web.browser) took 15
     START 2 processing files with meteor (for target web.browser)
     DONE 2 processing files with meteor (for target web.browser) took 1
     START 2 processing files with cosmos:browserify (for target web.browser)
     DONE 2 processing files with cosmos:browserify (for target web.browser) took 4
     START 2 processing files with fourseven:scss (for target web.browser)
     DONE 2 processing files with fourseven:scss (for target web.browser) took 7
     START 2 minifying app code
     DONE 2 minifying app code took 15446
     START 2 minifying app stylesheet
     DONE 2 minifying app stylesheet took 1252
   DONE 1 building for web.browser took 27571
   START 1 building for os.linux.x86_64
     START 2 linking the program
     DONE 2 linking the program took 18
     START 2 processing files with ecmascript (for target os.linux.x86_64)
     DONE 2 processing files with ecmascript (for target os.linux.x86_64) took 341
   DONE 1 building for os.linux.x86_64 took 1378
 END CAPTURE 0 building the application took 89492

[toverux]

Build times on hot reload were catastrophic for me in 1.2 (~20-40 seconds on an i7 with 8 cores and a bunch of gigabytes of RAM, and up to 1.5-2 minutes on a coworker's PC, that was almost unusable).
In 1.3, the app builds in 1 or 2 seconds, and it has a large codebase. I don't know what you have done to the build system, but thank you :+1:

I have no more excuses to take breaks now.

[HynesIP]

I was used to clicking save and wandering off to do something else while the Meteor project rebuilt. Not anymore. Awesome! Now I barely have time to clear the console and prepare for the refresh. Great job MDG!

[gsabran]

Still a big issue for me (on 1.3.2):

Top leaves:
| files.readFile...........................................4,439 ms (3581)
| files.readdir............................................3,870 ms (5694)
| other compileUnibuild (the app)..........................2,862 ms (2)
| files.stat...............................................2,627 ms (49252)
| files.realpath...........................................2,048 ms (3041)
| Babel.compile..............................................662 ms (276)
| other ImportScanner#_tryToResolveImportedPath..............620 ms (3772)
| files.lstat................................................609 ms (2158)
| files.writeFile............................................600 ms (7)
| other JsImage#write........................................513 ms (1)
| 
| (#10) Total: 22,634 ms (Rebuild App)
| 

I just can't wait 20s every times I press save. And why is the build spending so much time on file things while I'd usually save 1-2 files at once??? That's very frustrating and hurting my performance. I don't have a particularly large app either...

[gsabran]

I went back to 1.3 and it's 2-3 times faster

[ivansrdic]

Intel i7 3700, 12GB RAM, 2xSSD in raid 0, Windows 10 64bit.

| Top leaves:                                                                
| files.lstat.............................................24,820 ms (189056) 
| other compileUnibuild (the app)..........................5,646 ms (2)      
| files.readdir............................................2,500 ms (10862)  
| files.stat.................................................503 ms (5800)   
| other ImportScanner#_tryToResolveImportedPath..............364 ms (2632)   
| files.readFile.............................................319 ms (945)    
| Babel.compile..............................................137 ms (153)    
| CssTools.parseCss..........................................134 ms (54)     
| other PackageSourceBatch.computeJsOutputFilesMap...........122 ms (1)      
| files.realpath.............................................117 ms (169)    
| CssTools.stringifyCss......................................109 ms (1)      
| ImportScanner#_getInstallPath..............................101 ms (954)    
|                                                                            
| (#4) Total: 35,662 ms (Rebuild App)                                        
|                                                                            

I created a VM with Ubuntu 14.04 64bit (6GB RAM, 4/8 cores) on the same machine and the build times are 2s.
Same thing on my other pc and my colleague's windows laptop. Other colleagues that have Linux or OS X have build times less than 2.
And it isn't just this project, the todo project has almost the same build time.

Build times are the same on 1.3 and 1.3.x.

I tried searching everywhere for the files.lstat issue, but there is no answer.

EDIT: Tried reinstalling meteor but still same results.

EDIT 2: By removing babel/eslint from local and installing them globally, build time dropped to 5s of which files.lstat takes up 2s. But this problem isn't happening on Unix os so I don't consider this a solution.

[steve-ross]

i had some horrible build times and removing my .meteor/local/bundler-cache helped

[steve-ross]

However I'm on a 2011 Macbook Pro 16GB RAM & SSD and my app rebuild times are a little over 7 seconds. Here is the gist of my profile (instead of pasting it in)

https://gist.github.com/steve-ross/3899678ad3491f3d570f7a4475bfbd39

My slow times using 1.3.2.4 are on ClientTarget#minifyCss which takes about 4 seconds

[alamont]

By removing babel/eslint from local and installing them globally, build time dropped to 5s of which files.lstat takes up 2s. But this problem isn't happening on Unix os so I don't consider this a solution.

I can confirm that this works. However it is still slower as before and this 'solution' is far from ideal.

[patrickml]

@alamont i tried to do that however now im getting build errors with MUPX trying to build in production.

Archiving failed: ENOENT: no such file or directory, stat '/tmp/a05d3854-ddd6-4bf2-a73e-5351b5902df8/bundle/programs/server/npm/node_modules/.bin/eslint'

How did you install eslint globally just using -g?

Update: Re-running npm update and npm install --save after moving to global eslint fixed the issue above.

[alamont]

@patrickml I only removed the babel packages.

[steve-ross]

I installed eslint with npm install -g eslint didn't help at all on posix

FWIW here is the link to the Performance.md file for meteor-tool so you guys are aware that they are actively trying to fix the slow rebuild times: https://github.com/meteor/meteor/blob/be986fd70926c9dd8eff6d8866205f236c8562c4/tools/PERFORMANCE.md

[patrickml]

@steve-ross thanks for posting that. I think most of us are aware, and why we are posting the profiling time. My build times on save are significantly faster that what they were with 1.2, it's just the production bundling build is taking 90+ seconds so I had posted an entire profile

[patrickml]

After moving eslint to global I saw a ~30 second increase in production build time

Things to note:
--Application has been changed and is larger now
--I have a lot of local packages
--Most of the time is taken at the very end after DONE 1 building for os.linux.x86_64 took 2711 im not sure what is happening after that but that is where most of the time is taken.

https://gist.github.com/patrickml/56dc465816b903049816fa5d34374ec8

[gsabran]

Lol can you make a gist instead?

[patrickml]

@gsabran good point lol I just moved it to one

[ivansrdic]

I am using babel and eslint for code checking, and these were my steps:

1. Removed all devDependencies from packages.json
2. Installed the necessary ones globaly. For me it was:
   npm install -g babel-core babel-eslint eslint eslint-plugin-react
3. Cleaned up the local node_modules with npm prune
4. Referenced new eslint module location in my IDE (WebStorm).

The reason for much faster build times is that instead of 150 000 files in the node_modules directory, only about 22 000 remain. I'm not sure why is it necessary for meteor to scan all those files on every save. If there was a way to stop that, the build times would be 2s.
For now, I suppose making all packages global would be the best 'solution'.

1st build profiling gist: https://gist.github.com/ivansrdic/3d2daafccca10f723051896096752900
rebuild on save profiling gist: https://gist.github.com/ivansrdic/2a1c2cdd4c8f13c536836525326fda38

EDIT: As I suspected, moving all packages to global leads to 2s build times. It does break the app because the modules are not resolved.
global packages profiling gist: https://gist.github.com/ivansrdic/79344584219f9415ed7375116fb8475b

[richard-edwards]

@ivansrdic I moved all my dev dependencies to global as you mentioned. I'm getting a little better build time but it's still unacceptable at about 25 seconds on Windows 10, 19 seconds on my Mac. The app isn't even a big one, just doing some testing with the React branch of the Todo app.

[ivansrdic]

@redwards1966 Can you post profiling results results? Also, are you talking about initial build time when you run meteor or rebuild on save?

[ljack]

Any help from running meteor npm dedupe or would it require newer version of npm?

[alamont]

@ljack Running npm dedupe reduced my rebuild time from 50s to 10s. Still not great but it's usable.
Like @ivansrdic mentioned this is probably due to reduced number of files. After dedupe there remained only 23k files instead ok 200k+.

[richard-edwards]

@ivansrdic No, it's just the refresh time after I do a minor file change. Something as simple as adding a space to a file. Here is my top leaves:

| Top leaves:                                                                
| files.lstat..............................................3,688 ms (23374)  
| files.writeFile..........................................3,285 ms (1857)   
| Babel.compile............................................2,751 ms (223)    
| files.readFile...........................................2,207 ms (6361)   
| files.stat...............................................1,957 ms (29194)  
| other compileUnibuild (the app)..........................1,888 ms (3)      
| files.readdir............................................1,039 ms (5183)   
| other ClientTarget#minifyCss.............................1,032 ms (1)      
| sha1.......................................................874 ms (6900)   
| files.rename...............................................769 ms (1863)   
| files.rm_recursive.........................................642 ms (4)      
| files.realpath.............................................640 ms (1618)   
| CssTools.parseCss..........................................614 ms (1)      
| other JsImage#write........................................435 ms (1)      
| CssTools.stringifyCss......................................409 ms (1)      

[steve-ross]

just an idea for the files.lstat wonder if you could use git status and fallback to a real scan if the project wasn't in git?

[ghost]

Hi. Could someone explain or direct me to a page on how to produce the output which shows where build times are take long. such as redwards1966 post above.

I too am find horrific build times. I am using a clone of themeteorchef/base with minimal modifications at this point

[Slava]

@sandcastletech you can get this output by running Meteor with a special environment variable METEOR_PROFILE set to some number which acts as a minimal threshold for printing. You can read more here: https://github.com/meteor/meteor/tree/devel/tools#profiling

[ghost]

cheers @Slava and @steve-ross ! Thanks alot.

Here is a pastebin of my output. Hopefully someone can make heads or tails from this.

http://pastebin.com/Affggavp

[CTimmerman]

While building, conhost.exe is using 100% of one core of my 2.4 GHz i7; less output to the console should speed things up. Windows 10 Pro.

[richard-edwards]

Is anyone working on this? I feel like I'm working 8 hour days and getting about 1 hour of billable done and my client is going nuts with my progress so far. I'm willing to help any way I can to resolve this.

[gsabran]

I agree this should be a top priority issue, unless very few people are experiencing this, which is hard to assess. For me at the moment it's a often like Meteor is an ambitious framework for developers where you can't be developing 50% of the time because you're waiting for your changes to show up.
Rebuild should be almost instant, and it'd be nice to see MDG embrace things like webpack or other fast reloading packages that have been built to address those issues, and make sure they work 100% with Meteor as is done with minimongo etc. It's nice to know we'll be able to use any database with Apollo, but I'd rather have something that just works..

[flippyhead]

Another datapoint: we're also seeing that reloading when local packages change is even slower, sometimes upwards of a full minute for any change, even just to CSS.

[hitchcott]

@gsabran I also think this should be a big priority for MDG.

I'm a long time Meteor fanboy and was hoping, as usual, to use it for my next project. However I required a custom Semantic-UI theme with a bazillion includes. There's just no way I could deal with the reload times between saves, so I was forced to switch to webpack.

I'll probably only be able to use Meteor for prototyping and micro projects until this is sorted out.

[flippyhead]

FWIW here's the time profile for changing javascript in a package that local on the same disk. This is for a very small app on a 8 core machine with 16GB of RAM. Needless to say, 12+ seconds for every file change is nearly untenable.

=> Meteor server restarted                                              
| (#19) Profiling: ProjectContext prepareProjectForBuild
|  Building package pathable-ui              \
| ProjectContext prepareProjectForBuild........................12,394 ms (1)
| └─ _buildLocalPackages.......................................12,155 ms (1)
|    └─ IsopackCache Build local isopack.......................12,145 ms (5)
|       └─ Isopack#saveToPath..................................11,947 ms (1)
|          ├─ Builder#copyDirectory.............................8,894 ms (2)
|          │  ├─ Builder#_ensureDirectory.........................330 ms (1740)
|          │  │  └─ files.mkdir                                   260 ms (1738)
|          │  ├─ files.readdir                                    207 ms (1740)
|          │  ├─ files.lstat                                    2,127 ms (14916)
|          │  ├─ files.copyFile.................................4,767 ms (13160)
|          │  │  ├─ files.stat                                    296 ms (13160)
|          │  │  └─ other files.copyFile                        4,470 ms
|          │  └─ other Builder#copyDirectory                    1,458 ms
|          └─ Builder#complete..................................3,006 ms (1)
|             └─ files.renameDirAlmostAtomically................3,006 ms (1)
|                └─ files.rm_recursive                          3,005 ms (1)
| 
| Top leaves:
| other files.copyFile.....................................4,470 ms (13160)
| files.rm_recursive.......................................3,006 ms (3)
| files.lstat..............................................2,131 ms (14954)
| other Builder#copyDirectory..............................1,458 ms (2)
| files.stat.................................................308 ms (14148)
| files.mkdir................................................265 ms (1769)
| files.readdir..............................................232 ms (1949)
| files.readFile.............................................139 ms (699)
| 
| (#19) Total: 12,394 ms (ProjectContext prepareProjectForBuild)
| 
| (#20) Profiling: Rebuild Appi              \
|  Building the application                  \
| files.readFile                                                   12 ms (3)
| files.exists                                                     12 ms (4)
| files.writeFileAtomically.......................................240 ms (2)
| └─ files.writeFile                                              240 ms (2)
| Rebuild App...................................................6,945 ms (1)
| ├─ compiler.compile(the app)..................................2,569 ms (1)
| │  └─ compileUnibuild (the app)...............................2,568 ms (2)
| │     ├─ files.realpath                                         461 ms (2456)
| │     ├─ files.readdir                                          636 ms (4915)
| │     ├─ files.stat                                             487 ms (39771)
| │     └─ other compileUnibuild (the app)                        911 ms
| ├─ bundler.bundle..makeClientTarget...........................2,316 ms (1)
| │  └─ Target#make.............................................2,316 ms (1)
| │     ├─ Target#_runCompilerPlugins.............................419 ms (1)
| │     │  └─ plugin ecmascript...................................307 ms (1)
| │     │     └─ Babel.compile                                    229 ms (179)
| │     └─ Target#_emitResources................................1,839 ms (1)
| │        ├─ PackageSourceBatch.computeJsOutputFilesMap..........773 ms (1)
| │        │  ├─ ImportScanner#_tryToResolveImportedPath          400 ms (2527)
| │        │  └─ ImportScanner#_readFile                          213 ms (754)
| │        └─ PackageSourceBatch#getResources...................1,061 ms (90)
| │           └─ PackageSourceBatch#_linkJS.....................1,060 ms (90)
| │              └─ linker.fullLink...............................986 ms (1)
| │                 └─ linker Module#getPrelinkedFiles............978 ms (1)
| │                    ├─ linker File#getPrelinkedOutput          311 ms (186)
| │                    └─ getPrelinkedFiles toStringWithSourceMap 656 ms (1)
| ├─ bundler.bundle..makeServerTarget...........................1,459 ms (1)
| │  └─ Target#make.............................................1,458 ms (1)
| │     ├─ Target#_runCompilerPlugins.............................387 ms (1)
| │     │  └─ plugin ecmascript                                   273 ms (1)
| │     └─ Target#_emitResources................................1,052 ms (1)
| │        ├─ PackageSourceBatch.computeJsOutputFilesMap          300 ms (1)
| │        └─ PackageSourceBatch#getResources.....................747 ms (100)
| │           └─ PackageSourceBatch#_linkJS.......................746 ms (100)
| │              └─ linker.fullLink...............................670 ms (1)
| │                 └─ linker Module#getPrelinkedFiles............667 ms (1)
| │                    ├─ linker File#getPrelinkedOutput          312 ms (186)
| │                    └─ getPrelinkedFiles toStringWithSourceMap 348 ms (1)
| └─ bundler writeSiteArchive.....................................594 ms (1)
|    └─ bundler writeTargetToPath.................................566 ms (2)
|       └─ ServerTarget#write.....................................435 ms (1)
|          └─ JsImage#write.......................................420 ms (1)
|             └─ Builder#copyDirectory                            274 ms (22)
| 
| Top leaves:
| getPrelinkedFiles toStringWithSourceMap..................1,004 ms (2)
| other compileUnibuild (the app)............................911 ms (2)
| files.stat.................................................743 ms (46249)
| files.readdir..............................................640 ms (4938)
| linker File#getPrelinkedOutput.............................622 ms (372)
| files.realpath.............................................567 ms (2634)
| Babel.compile..............................................409 ms (368)
| files.readFile.............................................375 ms (1586)
| files.writeFile............................................248 ms (10)
| other PackageSourceBatch#_linkJS...........................145 ms (190)
| files.rm_recursive.........................................109 ms (372)
| 
| (#20) Total: 7,209 ms (Rebuild App)
| 
=> Meteor server restarted

[gsabran]

I'm currently considering moving my entire project out of meteor for that reason... I just can't get stuff done

[kachkaev]

@gsabran looks like I'm in a similar situation. After I got inspired by Meteor 1.3 in March (when it was in beta), I decided to move one rather old website from PHP+Symfony2 to the full-stack JS. Using Meteor, of course. As I progressed, the build times were getting worse and worse so for now I ended up hacking the app with gadicc/meteor-hmr package. React components refresh nearly instantly with it, but even little tweaks in the CSS files take at least 5-10 seconds to see. And that's on a rather decent Macbook Pro.

That particular website I work on is just a bunch of simple pages, so the gain of having DDP and other meteor advantages is not compensating the pain. So looks like I'll choose to go through another kind of pain – which is in searching for an alternative build solution and hoping to integrate the new great Apollo Stack there. All this is something I really don't want to do.

If MDG has got any plans on changing the current situation with build times, it would be great to know the plan. If a solution exists and it can be released soon, many of us will be much happier.

[flippyhead]

When changing a file in a dependent package the majority of time appears to be taken up by file copy operations. What was surprising to me though is just how many files are in this package:

$ find . -print | wc -l
$ 15760

The number of files we've actually created is around 30. The rest I assume are dependencies but even here we only have 5 atmosphere packages and another 6 NPM packages.

[steve-ross]

Thought I'd put this in a little perspective. LiveReload on a project we
have that is done in react and straight NodeJS is comparable to refresh
times we are seeing in Meteor on a very large project. Pretty sure they
know it sucks and there are some other threads out there dealing with
minification of css (which takes some time but is unnecessary in dev mode).
Just thought I'd throw that out there. We (http://oak.works) aren't
abandoning Meteor as we know the cycle between features blows away anything
else out there. Still would like to see rebuild times much faster granted
but, not even considering going elsewhere until there is a _real_ reason to
go elsewhere.

On Thu, May 12, 2016 at 7:31 PM Peter T. Brown [email protected]
wrote:

When changing a file in a dependent package the majority of time appears
to be taken up by file copy operations. What was surprising to me though is
just how many files are in this package:

$ find . -print | wc -l
$ 15760

The number of files we've actually created is around 30. The rest I assume
are dependencies but even here we only have 5 atmosphere packages and
another 6 NPM packages.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/4284#issuecomment-218914667

Oak.Works

Steve Ross - CTO
O 268-0444

M 344-8113
[IM] [email protected]

[s-ol]

Front-end changes using HMR barely take seconds to build but our backend takes up to, and often over ten minutes for a single build. That's far more than an inconvenience. A colleague just said after moving all devDependencies to global build time dropped to ~40s, we are also about to try meteor 1.3.3.

[csergiu]

I've moved my project to a Lubuntu VM, everything is fast now!

[Slava]

@csergiu was your previous (angry) comment about using Meteor on Windows?

[Themandunord]

Wow, I hate this new feature from meteor 1.3... reload times it's so slow...
~18s for a simple project...

Anyone have a workaround for this ?

[renatosvo]

I had same problems with hot reload taking forever...
my huge css file inside client folder was the problem. Moved it to public, everything runs fine.

-- i'm sorry for my bad english

[Batistleman]

Can I help somehow to reduce this? (I'm at ~18s)

[wwlweihai]

yes it is too slow when code change.

[Batistleman]

@MDG Is it on the roadmap to make this faster in future versions?

[vleipnik-miovision]

Why hasn't there been a proper response from @MDG on this yet? At the very least, please let us know you are working on it. I am getting very concerned about the decision to use Meteor in a production environment as a result of this issue.

[gsabran]

This is the third most commented issue on Meteor (for good reasons) and it's frustrating to hear nothing at all from MDG... It should be top priority

[Batistleman]

perhaps @benjamn could jump in to give us some hints? :-)
(For example how we could help to solve this issue?)

[anuragagarwal561994]

I am facing the same issue and I identified some problem with meteor's new application structure,
Meteor 1.3 application structure supports imports directory, now any js file (irrespective of being on only client side) change performs a full build of application which takes a lot of time.

May be somehow if it can be mapped if the files are loaded only on client/server a significant performance gain can be expected.

Rest babel and sass compilation takes time

[nbrady-techempower]

I agree with the build time problems here, using windows 10.. ~20secs for a growing React/Meteor project for me. but also note that @benjamn is killing it with fixes in every department. I'm sure he will respond to this as soon as he can. He's been working pretty hard

[jedwards1211]

@hitchcott you didn't want to just use Webpack with Meteor?

[fyllepo]

Thought I was the only one..

Windows 8.1, i5 CPU, 8GB ram, 30-45sec refresh time per change, sometimes it goes over a minute.

I'm running the Telescope Nova project.

[nbrady-techempower]

@fyllepo I just upgraded to 1.4-beta.1 and saw a significant drop in refresh times from about 33 seconds to 12 seconds on the exact same specs as you. My other environment is Windows 10 latest dev preview, i7 16GB ram and 11 second builds on refresh.

[fyllepo]

Hey @nbrady-techempower, thanks for the suggestion, I've updated to 1.4-beta.1 and got out my trusty stopwatch, compile times are roughly 45-55 seconds, if anything it just seems a little bit longer..

Awh, I have a feeling I may need to just switch environment. I don't suppose you know anything else which may help tune this up a little?

[nbrady-techempower]

@fyllepo Sorry I don't. I imagine your build packages must be a lot larger than mine.

[ljack]

Any help from running 'rm -rf node_modules && npm i && npm dedupe' or 'rm
-rf node_modules && meteor npm i && meteor npm dedupe' ? Once helped a lot
for one of my projects.

2016-06-27 22:33 GMT+03:00 Philip Elliott [email protected]:

Hey @nbrady-techempower https://github.com/nbrady-techempower, thanks
for the suggestion, I've updated to 1.4-beta.1 and got out my trusty
stopwatch, compile times are roughly 45-55 seconds, if anything it just
seems a little bit longer..

Awh, I have a feeling I may need to just switch environment. I don't
suppose you know anything else which may help tune this up a little?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/meteor/meteor/issues/4284#issuecomment-228850612, or mute
the thread
https://github.com/notifications/unsubscribe/AC-_MmngQOaeN3_TUuNIripONmc9cX8iks5qQCWJgaJpZM4EJ96g
.

[fyllepo]

@ljack Thanks for the suggestion, I've given both command chains a try and no noticeable improvement.

I am getting crashes after a few rebuilds in a row though,
=> Client modified -- refreshing (x11)(node) warning: possible EventEmitter memo ry leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit. Trace at StatWatcher.addListener (events.js:160:15) at Object.fs.watchFile (fs.js:1175:8) at Object.files.watchFile (c:\tools\fs\files.js:1486:10) at Object.watch (c:\tools\fs\safe-pathwatcher.js:85:9) at Watcher._watchFileOrDirectory (c:\tools\fs\watch.js:469:35) at c:\tools\fs\watch.js:547:18 at Array.forEach (native) at Function._.each._.forEach (c:\Users\Phil\AppData\Local\.meteor\packages\m eteor-tool\1.3.2_4\mt-os.windows.x86_32\dev_bundle\lib\node_modules\underscore\u nderscore.js:79:11) at onWatchEvent (c:\tools\fs\watch.js:536:11) at thenCallback (c:\tools\utils\func-utils.js:37:18) at c:\Users\Phil\AppData\Local\.meteor\packages\coffeescript\1.0.17\plugin.c ompileCoffeescript.os\npm\node_modules\meteor\promise\node_modules\meteor-promis e\fiber_pool.js:33:40

[Batistleman]

I've update to 1.3.4 and tried the dedupe trick, no luck unfortunately. Still ~ 20 sec.

Also, since 1.3 most of my files are not in a /client or /server folder. They are abstracted and get imported in. (except publications & private server things, because this could be a possible security leak?)

I have the impression changing these files triggers both a server and client reload, although they might only be imported by the client?

[nerdmed]

@benjamn great work! The 1.4 beta has nearly 30% better build times! Maybe there is even more improvement with node 6? Its still not where we want it to be for larger projects but i can feel the improvement 👍

1.3 - (#2) Total: 25,102 ms (Build App)
1.4 - (#2) Total: 18,138 ms (Build App)
-> ~28% faster

1.3 - (#4) Total: 5,081 ms (Rebuild App)
1.4 - (#4) Total: 4,126 ms (Rebuild App)
-> ~20% faster

[nbrady-techempower]

@nerdmed 4 second build times? what's your environment? I'm on 1.4-beta.4 with a fairly small app at 12 second builds. Also, I'm not sure how to tell that it's using node 4 since meteor node --version shows 0.10.x

[nerdmed]

@nbrady-techempower - 4 seconds is the rebuild time for a fairly big app. I am on 2 year old MB Pro - but its powerful 😈

you can check the node version in the meteor shell

meteor shell
> process.version
'v4.4.6'

[nbrady-techempower]

@nerdmed been developing with meteor for a few months and still have done much in the shell, thank you!

[i474232898]

Windows 10 x64, ssd, i5, 8RAM - around 20 seconds with almost empty project.
Ubuntu 16.04 on the same machine - about 3-4sec running the same project

[lyquocnam]

windows 7 x64 take about 10-12s on meteor run

[paralin]

Still pretty slow on 1.4, around 15-20 seconds for a really small app.

[Batistleman]

Unfortunately, there seems to be no progress in this regard.

For those who like to program visually, are using react, and like speed you might give react-storybook a try. (Although setting up css/less loading is quite tricky)

[vsheyanov]

We started experiencing this weird problem on Macs only (2 developers) while it works fine on Windows. Normally it's Windows who's in trouble...

from Mac: https://gist.github.com/vsheyanov/a5abb8b3a9305811781d8cc694b143c1
linker File#getPrelinkedOutput.........................139,501 ms (1)

from Windows: https://gist.github.com/sdemidov-ru/7561e7cfd5051e72bdc8efddaca0faca

As you can see build time for mac is 200 seconds.

We are using thereactivestack.

I've traced recent changes and sorted out that importing 2 dependencies are causing the issue:

• https://www.npmjs.com/package/fb
• https://www.npmjs.com/package/twitter

When removed, build time returns to normal (6-8 seconds for big project).

Any suggestions, how to try fixing this?
What does linker File#getPrelinkedOutput do and how 1 call may screw build up? In console it just looks like that build process is frozen and _node_ process takes 100% CPU

[lope]

I'm building a smallish app. And build times are quite unpredictable. On the 1.3.4.4 release I recently counted 46 mississipi seconds (now I've turned on profiling to get accurate time) for changing one line in /server/foo.js file auto-rebuild.

Out of desperation I've moved my project into a RAMdisk (a little risky for possible data/work-loss) cos I didn't know what else to try, until I scratched around and found this.

I'm using a 2nd gen, 2core 4thread 2.7ghz i7 with a 500MB/s SSD and 16GB RAM PC with 4.4 linux kernel.

I've just upgraded to 1.4 beta 9 and it seems a lot faster but I've not used it much yet.

I'm really not using much. I've got the normal react flowrouter react-mounter stuff fourseven:scss http accounts-password and 2 NPM modules (cheerio and fs)

[Alino]

I am stuck on meteor 1.2.1 and I though the build time sucks because I have mess in my project and I am on an old meteor version. But now as I see this issue, I don't want to write meteor apps anymore. This is a huge problem and MDG should prioritize this on top

EDIT: the main problem for me is the rebuild after each file is saved. This also affects velocity integration tests. No one wants to wait 30 seconds to see if a single test is passing or not, every time you make a change. This gives people time to open facebook and social media crap, and procrastinate.

[s7dhansh]

Build times have improved a lot between 1.3.0 and 1.3.4.

As highlighted above, the main problem that remains is the rebuilding of entire app after every edit, even the client files. I learnt the hard way to ensure that all client files are in a client folder. Meteor suggests imports/ui but instead using imports/client does the trick.

[lope]

I was having build times of around 46 sec in 1.3.4.4. Upgraded to 1.4-beta.9 it's much better. 5.7 sec. now 1.4-beta.14 is 5.2 sec. 5.2 sec is workable for me, now that I'm more familiar I can write more code between reloads. I'd prefer 2 sec though (or less obviously)

@s7dhansh that sounds amazing. Does it break SSR?

EDIT 2: wowee! s7dhansh my reload times are down to 1.9s for a new minor jsx edit, and 1.5s for an 'undo' edit.

This is amazing! MDG FTW!!!

[paralin]

So to be clear - you say the fix is to have a /imports/client folder or a /client/imports folder? Which one?

[gsabran]

Does /clients/imports make things faster than just /clients?

[paralin]

@benjamn @gsabran /clients ?? I've never heard the s on there before.

[gsabran]

Ah yeah I just copied pasted the line before :) What the deal with the s @benjamn ?

[paralin]

I think it's a mistake @gsabran , it's been client for years.

I've just updated my app to have all client only things in /imports/client/ and it is WAY faster, thanks for the tip @s7dhansh

[gsabran]

Any idea whatimports is changing?

[paralin]

@gsabran It's the standard way to set up a modular meteor app these days, you use ES6/TypeScript imports and an "imports" directory to import your code from.

Anything outside an "imports" directory is compiled together into 1 big file.

The best way to do it is to put an "app.ts" or something in your client directory and import a root component from your "imports" directory and go from there.

[benjamn]

You can have an ./imports/ directory anywhere, but /client and /server have to be in the root application directory in order to have special meaning.

Edit: This is wrong, you can have any of these directories anywhere (except inside other special directories like node_modules, packages, etc.).

[gsabran]

Hum all my code is under /src so I have /src/client and src/server and I can't import anything in /src/client from anywhere in src/server so it looks like there is still some special meaning even if the folders are not at the root

[bryaan]

It has been months now and we have yet to see any real progress. I dove into webpack, HMR, babel, react, and nodejs because this wasn't being prioritized and this is in no way a small issue. I'm sure thousands of dev-hours have been wasted not only waiting for a oneliner change to update, but also in the loss of focus on the task at hand. I _strongly_ recommened forking davezuko's react-redux-starter-kit (I replaced redux with mobx). Meteor is a nice idea, but it's just not worth it. Good luck everyone.

[gsabran]

@paralin I'm aware of the ES6 import and I'm doing everything with that, but I didn't know the foldering would change things. Are you saying that any directory under /imports will be compiled in its own file?

[Akryum]

You can have an ./imports/ directory anywhere, but /client and /server have to be in the root application directory in order to have special meaning.

@benjamn Are you sure about this?

[nadeemja]

We should crowdsource a money prize to whoever solves this issue. I imagine, from the size of this thread, it would quickly become a large sum. Could that incentivise someone to solve this issue and send a PR? What do you think? I pledge $10, but might give more.

[bryaan]

@nadeemja someone proposed this in the past. If you want it done right you have to do it yourself 👍

[Batistleman]

@nadeemja I'd pledge € 100, might give more if it's really fast :-)

[nadeemja]

@BryanARivera Was not aware of that. I'd look into making a crowfunding with a simple criteria "Whosoever gets their PR merged by MDG with a commit stating 'Fixes #4284'" wins.

@Batistleman Very cool!

But, I have no credibility in the community, and people shouldn't and wouldn't trust a site I put up. Someone known and trusted in the Meteor community must verify the legitimacy and endorse the crowdfunding. Any nominations?

[benjamn]

@Akryum I stand corrected! Here is the relevant code. As you can see, the directory patterns for client and server are part of the anyLevelExcludes, as opposed to topLevelExcludes.

[bryaan]

@nadeemja bountysource.com

[benjamn]

I look forward to your pull requests, everyone!

If you would like to contribute an improvement, at this point I think it would be best to open a new issue about the specific problem you're planning to solve, and then refer to that issue in the pull request that solves it, rather than attempting to fix this issue (#4284) with one PR.

If you haven't read Contributing.md, it's worth your time.

Cheers.

[nadeemja]

@benjamn

Is there an overview of the specific issues contributing to the build times?
Perhaps someone could make one and have it become a "milestone"?

[benjamn]

@nadeemja Yes! See https://github.com/meteor/meteor/blob/devel/tools/PERFORMANCE.md for an overview of what parts of the build tool tend to cause performance problems, and under what conditions.

[steve-ross]

Really hard not to write a rant about everyone commenting on this issue. I
mean the history is here, the problem is obvious. Contribute or scroll up.
Your "me too" isn't helping. Not trying to be a jerk here but seriously,
pretty sure everyone is aware that there is a problem.

On Fri, Jul 15, 2016 at 2:38 PM Ben Newman [email protected] wrote:

@nadeemja https://github.com/nadeemja See
https://github.com/meteor/meteor/blob/devel/tools/PERFORMANCE.md for an
overview of what parts of the build tool tend to cause performance
problems, and under what conditions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/meteor/meteor/issues/4284#issuecomment-233033067, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AASJh2CC80HC-d_UHD5INznTNrvHx-YKks5qV9OVgaJpZM4EJ96g
.

Oak.Works

Steve Ross - CTO
O 268-0444

M 344-8113
[IM] [email protected]

[andrew-wharton]

TL;DR: It would seem that any code you register to be called in Meteor.startup(function () {...}) will block the server restart. One solution is to wrap the code inside the Meteor.startup() callback with a setTimeout().

To add a datapoint that may help someone, I had an issue where my app was rebuilding in about 20-30 secs, but taking 1-2 mins for the Meteor server to restart.

I eventually discovered the problem was related to a "observeChanges({added: function() {...}})" handler I had on one of my collections.

On every startup, this handler would be called for each document in the collection, and would block server startup until it had finished. So as the collection grew in size, it would take progressively longer and longer. Once I was up to ~30 000 documents, it was getting really slow, (blocking for 1-2 mins or longer).

My solution was to add a setTimeout() for registering the handler, which brought the server startup time back to almost instant.

[s7dhansh]

@paralin I am not using flowrouter-ssr so I can not tell. If you can, it will be awesome.

Though my guess is that it would not, considering the client files are not at all available on the server. In which case my workaround would be to write a shell script wrapper for mupx which will just rename the folder and then deploy.

[s-devaney]

If /imports/client is faster why is /imports/ui the "best practice" in the Meteor guide?

[lawrentiy]

| Top leaves:
| linker File#getPrelinkedOutput.........................303,597 ms (1)
| files.readFile..........................................43,719 ms (3591)
| other plugin webpack:webpack............................36,444 ms (2)
| other ServerTarget#write................................16,788 ms (1)
| ImportScanner#_findImportedModuleIdentifiers.............8,133 ms (959)
| meteorNpm.runNpmCommand..................................2,880 ms (1)
| files.realpath...........................................2,369 ms (3598)
| toStringWithSourceMap (app)..............................2,083 ms (1)
| other files.withCache....................................1,716 ms (5)
| files.readdir............................................1,150 ms (6738)
| files.stat.................................................967 ms (18157)
| other PackageSourceBatch#_linkJS...........................707 ms (248)
| other plugin ecmascript....................................618 ms (2)
| other PackageSourceBatch.computeJsOutputFilesMap...........565 ms (2)
| other Resolver#_joinAndStat................................370 ms (1643)
| other JsImage#write........................................363 ms (1)
| files.writeFile............................................354 ms (479)
| Babel.compile..............................................332 ms (155)
| ImportScanner#_getInstallPath..............................279 ms (1165)
| other Resolver#resolve.....................................239 ms (2749)
| other Target#_runCompilerPlugins...........................235 ms (2)
| sha1.......................................................225 ms (2702)
| other compileUnibuild (the app)............................195 ms (2)
| files.lstat................................................170 ms (905)
| runJavaScript packages/underscore.js.......................160 ms (6)
| other linker Module#getPrelinkedFiles......................144 ms (1)
| Isopack#getUnibuildAtArch..................................134 ms (5695)
| files.rm_recursive.........................................126 ms (4)
| other Resolver#_resolveNodeModule..........................112 ms (223)
| other ClientTarget#write...................................109 ms (1)
|
| (#2) Total: 430,274 ms (Build App)

The worst result ever! Whos next! It stay happened after I put all my packages direct into project in cause of limited npm support. its impossible create wrapper for all npm packages in my meteor-package (for example React).
I thought it was my mistake...
I prefer npm-packages because of slow updating of atmosphere wrappers for they.
I`he tried to use webpack to speed up react ui build.

And after I turn off the Internet, the time become better, but not acceptable:
| (#2) Total: 71,467 ms (Build App)

@MDG, what is happing? My faith will go out, how can I help?!?

PS:
i5 8Gb, SSD
Meteor 1.3.4.4

[benjamn]

@lawrentiy four possibilities here:

1. Your hard drive is failing.
2. You're running out of memory and swapping like crazy.
3. Your laptop battery was critically low and so your computer is running slowly to conserve power. Believe it or not, this happens! Never attempt any kind of performance profiling unless you're plugged into wall power.
4. You're hitting a very strange bug that you should make every effort to reproduce so that we can fix it.

[Akryum]

@lawrentiy I see that you are using the webpack:webpack package. When I used it for one of my project, I found out that wepback was causing a complete server refresh (meteor building literally all the files again), like if you just had started the app.

[lope]

@lawrentiy if you're using a mac it could be faulty. Macbooks often overheat and crap out after a few years, then go into ultra low performance mode all the time I don't know if this was the specific video where the issue was described, but one of his: https://www.youtube.com/watch?v=e4zo8mVpxvc

[lawrentiy]

@benjamn

• 
  
  1. Disk we can`t ever consider - I will check someway
  
  
• 
  
  1. During such long build meteor (node process) eat 1.5Gb instead of 5ooMb memory. But not the full available
  
  
• 
  
  1. It always stays on base station - impossible
  
  
• 
  
  1. Only one thing I`he noticed, It come on after I put a lot of my files from packages direct into project
     
     @Akryum
  
  
• 
  
  1. webpack:webpack - if file doesn`t exists in "client" folder, yes - changes lead to server rebuild.
     
     @lope
  
  
• 
  
  1. I`m not a macuser, luckily or unluckily ))
  
  

After all, my strategy will so:

• [ ] 1. Issue is package issue
• [ ] 1a. Check, if problem repeat at different computer (git clone)
• [ ] 1b. Check, if it depends on webpack
• [ ] 1c. Try to revert to commit where there was not such issue
• [ ] 1d. One by one repeat commits and find reasonable changesets
• [ ] 2. If 1 wont help or wont repeat
• [ ] 2a. Change SSD to another one using clone harddrive
• [ ] 2b. hm... no ideas

As you understand, check won`t be very fast. But I will do all, what i can.

PS: That long build not always happen.

PPS: Thnx all you for help and offers. You return faith to me)))

[lawrentiy]

@benjamn, please, take a look.
That is the related issue to my problem: #5863

That is the line with slow computation: https://github.com/meteor/meteor/blob/baa3f6a152af96ff1e7a7f9f0e00c86c9cd922ee/tools/isobuild/linker.js#L572

@eXon, please, take a look too.
It is required add webpack packages to repeat that bug:
webpack:webpack
webpack:react
webpack:css
webpack:assets

Using successive elimination method I found, that only two lines of one file in whole project (in server folder)
import {SvgIcon} from 'material-ui' console.log(SvgIcon);`
brings to:

linker File#getPrelinkedOutput..........................59,656 ms (1)

At first if i write:
import {ToggleStar} from 'material-ui/svg-icons'
console.log(ToggleStar);
then issue go away and all build as usual.

If I removed line with multiple assignment at compiled material-ui/svg-icons/index.js file
then all is fine and line with "linker File#getPrelinkedOutput" go away too.

I found as much as i can.
I`ll be very pleasant, if you, @benjamn or somebody else can tell me. What the best way to fix it.
My deadline coming soon...

Thanx for help!

[paralin]

@benjamn @lawrentiy Promising set of observations, any work towards fixing this?

[lawrentiy]

@paralin
Repository with project. Issue happens everytime to me.
https://github.com/lawrentiy/meteor-slow-build-bug

[lawrentiy]

Finally, I`ve put all code that use material-ui, react etc into client path. It helps to improve server part build to lest then 60 seconds (first start) and less then 8 seconds (next rebuilds)
The most time spent to files.readFile (30 sec - first start and 2-3 seconds - rebuild).
And it is on SSD drive. I will try to create RAM-drive to decrease that time.

There is some questions about SSR, but it can be solved during production build.

[Akryum]

Is usage of lstat necessary during the build process? It's quite slower that stat (~30% slower) on my Windows and it would save a few seconds.

[sebakerckhof]

It also occurs to me that whenever Meteor is running my McAfee antivirus is going through the roof. It probably wants to scan the huge amount of little files Meteor creates.
The problem is that I can't turn McAfee off since it's company policy. I suspect this might be the case for a lot of windows developers working in enterprise environments where these kinds of policies are common.
Since the AV-scanner is using a lot of CPU, the build times are even slower than they already are.

[Akryum]

I had a performance boost too while turning my Anti-Virus off.

[jedwards1211]

@sebakerckhof you could try using Webpack to bundle your files; it doesn't create any intermediate files, and in dev mode serves everything completely from memory.

[jedwards1211]

@sebakerckhof (though I don't know what the case might be when using @eXon's webpack plugin). It should at least not thrash your AV if you just have a separate webpack-dev-server process, or in production a webpack process outputting the bundles into your meteor folder from source code that lives outside your meteor folder. I can say though, even without AV, I've had Meteor post 1.0.5 take a long time on my webpack bundles.

[mxs]

@lawrentiy I got the same issue as you after upgrading to 1.3.5.1 from 1.2

Top leaves:
| linker File#getPrelinkedOutput.........................485,098 ms (1)

However this _magically_ dissapeared for me without moving files around. Are you able to reproduce this consistently?

[jedwards1211]

@benjamn I think making Isobuild use Webpack behind the scenes is the most likely way to solve this issue. I've never had these kind of performance problems with babel-loader. It's probably possible to make a custom resolver for handling Meteor packages with Webpack.

[jedwards1211]

@benjamn Or possibly you could just make a custom webpack loader for meteor packages.

[jedwards1211]

@benjamn I'm sure it would be hairy, but if you're willing for Isobuild to use Webpack I'd at least look at what it would take to make a PR.

[benjamn]

@jedwards1211 Knowing what I know about the iso* system, I'm afraid it doesn't really make sense to use Webpack as an implementation detail, so I can't recommend attempting a pull request.

I appreciate the feedback, though I must also note that it's possible to edit GitHub comments rather than posting a series of separate comments, each @mentioning me and generating a separate email for everyone subscribed to this issue.

[jedwards1211]

Well, what are you thinking it would take to fix this? My vague impression is that a major refactoring/design changes are needed. And I certainly wouldn't trust myself to roll my own bundler that works as well as Webpack.

[benjamn]

I mean, what about simply turning off your antivirus scanner for a certain directory? Isn't that a major contributing factor for many Windows users?

[jedwards1211]

I've always had the issue with 1.2+ on OSX and no virus scanner.

[sebakerckhof]

It's definitely a big factor (although it's also slow without). But often in large companies you have to use the laptop of the company and it has policies that disallow one to turn off the antivirus. At least that's the case in the companies i work for.

[lope]

The best anti-virus and performance improvement for windows is to delete your hard drive partitions and install Linux.

[jedwards1211]

If you can afford to stick with Meteor 1.0.5, it's worth it for the better performance.

[turbobuilt]

If you are on Windows 10, the solution is to install Windows Subsytem for Linux. Linux performance on windows

[rwuttke]

The only problem I am really having with Windows 10, is running two projects at the same time under the Windows Subsystem for Linux

$ meteor --port 3002
Retrying after error { [Error: SQLITE_IOERR: disk I/O error] errno: 10, code: 'SQLITE_IOERR' }
Retrying after error { [Error: SQLITE_IOERR: disk I/O error] errno: 10, code: 'SQLITE_IOERR' }
/home/rwuttke/.meteor/packages/meteor-tool/.1.4.0-1.13j49n2++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:165
      throw error;
      ^

Error: SQLITE_IOERR: disk I/O error
    at Error (native)

I have two sessions open, I run meteor in one session and attempt the meteor --port 3002 in the next session and get the error.

Just to check, I stop the first session and run the meteor --port 3002 on this app, and it works.

It seems that if I attempt to call meteor whilst another instance of meteor is running, it fails.

Note this includes

meteor help run

If a meteor instance is running and I call that

$ meteor help run
Retrying after error { [Error: SQLITE_IOERR: disk I/O error] errno: 10, code: 'SQLITE_IOERR' }
Retrying after error { [Error: SQLITE_IOERR: disk I/O error] errno: 10, code: 'SQLITE_IOERR' }
/home/rwuttke/.meteor/packages/meteor-tool/.1.4.0-1.13j49n2++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:165
      throw error;
      ^

Error: SQLITE_IOERR: disk I/O error
    at Error (native)

[paralin]

I know this isn't particularly helpful but I've completely dropped Meteor now in favor of other projects (webpack 2, angular 2, base node for api). Just because it seems that as Meteor moves towards being more based on NPM, the less it actually provides to me besides a subpar slow build system and a nicely integrated Mongo live sync channel. This isn't to say that Meteor isn't an amazing project and doesn't deserve having this problem fixed. But i think the days of having a single tool do everything are past us.

Best of luck guys!

[turbobuilt]

@paralin I'm all for decoupling when possible, because you get more control. But I just don't see anything as easy to set up as Meteor that provides reactive updates. Also, Meteor methods are still a lot simpler than any REST functionality in my opinion. Additionally Meteor's bundled use of Fibers which allow writing synchronous style code should not be underestimated. Throw in the built in authentication system, and you've got something that I think is actually very worth having for many projects. obviously if you don't need many of these features such as reactivity, then Meteor may not be right for your project, but if you do, I still think that it is a great value-add. If you run it using the new Windows Subsystem for Linux, it is much faster.

[paralin]

@dtruel there's a few packages like racer that do reactive publishing but nothing as easy as meteor so you're right in that one.

Fibers aren't necessary anymore with async and await in typescript which leverage promises to allow you to write a more linear code style exactly as in meteor. Some of the meteor devs are working on Apollo which is way better than meteor methods for backwards compatible apps and scalability. It allows for dynamic queries as well and I think they intend to make it be a part of the core of meteor eventually.

For reactivity you can use Angular or React or even Blaze via npm now. That's not so special anymore. Sure Tracker is pretty cool but rxjs makes it a bit obsolete.

Meteor is awesome and I've used it for many years now but I think it has fell behind in a lot of critical areas for real apps, which probably will be addressed here eventually but not least enough for me. That's all.

[ansaries]

| Top leaves:
| files.writeFile.........................................52,746 ms (510)
| composing source maps...................................32,701 ms (1)
| CssTools.parseCss........................................7,187 ms (77)
| CssTools.stringifyCss....................................5,119 ms (1)
| files.readdir............................................3,836 ms (13083)
| files.realpath...........................................3,812 ms (3633)
| files.lstat..............................................3,661 ms (16302)
| ImportScanner#_findImportedModuleIdentifiers.............2,515 ms (709)
| files.readFile...........................................2,309 ms (4754)
| CssTools.rewriteCssUrls..................................2,220 ms (77)
| other compileUnibuild (the app)..........................2,014 ms (3)
| files.stat...............................................1,810 ms (18694)
| other files.withCache....................................1,695 ms (7)
| other mergeCss...........................................1,691 ms (1)
..... i removed less than 1 sec.
|
| (#2) Total: 147,072 ms (Build App)

Meteor 1.4.01.
Dual Intel Xeon X5675 3Ghz 6 Core. x 2
16GB RAM
SSD
Windows 10.

I have just created a boilerplate using socially tutorial to start my project and included only a few custom and open source libraries after which it is taking more than 2 minutes. I have already moved everything in Client folder as otherwise it was taking more than 3 minutes.

Following is my package.json:
"dependencies": {
"angular": "^1.5.7",
"angular-animate": "^1.5.3",
"angular-aria": "^1.5.8",
"angular-cookies": "^1.5.8",
"angular-google-maps": "^2.3.2",
"angular-material": "^1.1.0-rc.5",
"angular-messages": "^1.5.8",
"angular-meteor": "^1.3.9",
"angular-resource": "^1.5.8",
"angular-sanitize": "^1.5.7",
"angular-simple-logger": "^0.1.7",
"angular-sortable-view": "0.0.15",
"angular-translate": "^2.11.1",
"angular-translate-loader-partial": "^2.11.1",
"angular-ui-router": "^0.2.18",
"angular-utils-pagination": "^0.11.1",
"fs": "0.0.2",
"gm": "^1.22.0",
"imagemagick": "^0.1.3",
"imagemagick-stream": "^4.1.0",
"ionic-sdk": "^1.2.4",
"is-property": "^1.0.2",
"meteor-node-stubs": "~0.2.0",
"mobile-detect": "^1.3.3",
"ng-file-upload": "^12.0.4",
"ng-img-crop": "^0.2.0",
"perfect-scrollbar": "^0.6.11",
"underscore": "^1.8.3"
},
"devDependencies": {
"babel-eslint": "^6.1.2",
"eslint": "^3.1.0",
"eslint-config-airbnb": "^9.0.1",
"eslint-import-resolver-meteor": "^0.2.4",
"eslint-plugin-import": "^1.10.3",
"eslint-plugin-jsx-a11y": "^2.0.1",
"eslint-plugin-meteor": "^3.6.0",
"eslint-plugin-react": "^5.2.2"
}

[linvi]

Is the team doing anything to fix these performances issues?
I can see that the post has been open in April 2015 and the performances still seems to be pretty bad.

[jedwards1211]

I've been experimenting with running my Meteor/React app through straight Babel/Webpack, instead of running it through Meteor/Isobuild (this approach doesn't work for Blaze right now). I only run meteor to initially download and build core meteor packages. So far...great success! And since this doesn't write anything to disk (if you disable babel caching, as far as I know), it would probably be a workaround for people suffering from these issues.

On the server side, you have to require boot.js from .meteor/local/build/programs/server, and then require babel-register with a custom resolveModuleSource for shimming Meteor modules.
On the client side you use Webpack with meteor-imports-webpack-plugin. Easy enough!

I put together an app skeleton here: jedwards1211/crater
Comes with react-hot-loader beta 3, and automatic server restarting thanks to piping, and also server-side rendering.

[drewmoore]

You can still follow the Meteor docs' recommended structure of putting client-side code in /imports/ui/.... You just have to specifically import each view's .js file before your router declarations. Like anything else under /imports, it will be ignored unless deliberately imported. I'm currently switching my app over to using this approach and version 1.4. So far, we're getting better results than with the old global declarations.

[jedwards1211]

@drewmoore Yeah I _could_ but re-inverting control and running my app code how I want to has a lot more advantages.

[jeremyfourna]

Hello,

On Meteor 1.4.1.2 my cold start for meteor is the following :

| Top leaves:
| files.readFile..........................................10,108 ms (1560)
| files.readdir............................................8,750 ms (673)
| meteorNpm.runNpmCommand..................................7,178 ms (1)
| Babel.compile............................................3,904 ms (206)
| ImportScanner#_findImportedModuleIdentifiers.............2,478 ms (633)
| other plugin ecmascript..................................1,517 ms (2)
| other plugin mquandalle:jade.............................1,474 ms (1)
| files.rm_recursive.......................................1,117 ms (4)
| files.stat.................................................925 ms (5241)
| linker File#computeAssignedVariables.......................622 ms (41)
| files.realpath.............................................589 ms (506)
| files.writeFile............................................500 ms (389)
| other runJavaScript packages/meteor.js.....................456 ms (7)
| wrapped.fs.readFileSync....................................420 ms (192)
| other runJavaScript packages/promise.js....................379 ms (5)
| files.mkdir................................................370 ms (45)
| linker File#getPrelinkedOutput.............................370 ms (124)
| other PackageSourceBatch#_linkJS...........................337 ms (188)
| getPrelinkedFiles toStringWithSourceMap....................337 ms (3)
| other Isopack#ensurePluginsInitialized.....................312 ms (234)
| other files.withCache......................................246 ms (5)
| CssTools.stringifyCss......................................227 ms (1)
| other runJavaScript packages/caching-compiler.js...........211 ms (3)
| other Target#_runCompilerPlugins...........................204 ms (2)
| runJavaScript packages/underscore.js.......................203 ms (9)
| CssTools.parseCss..........................................177 ms (6)
| other compileUnibuild (the app)............................172 ms (2)
| files.lstat................................................168 ms (582)
| composing source maps......................................166 ms (1)
| other PackageSourceBatch.computeJsOutputFilesMap...........166 ms (2)
| other JsImage#write........................................161 ms (1)
| runJavaScript packages/html-tools.js.......................149 ms (2)
| sha1.......................................................130 ms (2145)
| other ClientTarget#write...................................114 ms (1)
| other Resolver#_joinAndStat................................112 ms (1643)
| 
| (#2) Total: 66,297 ms (Build App)

My PC config :

• Intel® Core™ i3-4030U CPU @ 1.90GHz × 4
• Ubuntu 16.04 64 bits
• HDD
• RAM 3.7 Go

An my hot reload :

| Top leaves:
| meteorNpm.runNpmCommand..................................5,819 ms (1)
| files.readFile...........................................5,754 ms (1195)
| other plugin mquandalle:jade.............................1,257 ms (1)
| files.readdir..............................................611 ms (191)
| files.rm_recursive.........................................453 ms (26)
| files.realpath.............................................333 ms (270)
| Babel.compile..............................................275 ms (206)
| files.stat.................................................267 ms (4070)
| files.lstat................................................248 ms (426)
| files.writeFile............................................219 ms (7)
| other JsImage#write........................................166 ms (1)
| other Target#_runCompilerPlugins...........................135 ms (2)
| wrapped.fs.readFileSync....................................129 ms (149)
| other PackageSourceBatch.computeJsOutputFilesMap...........123 ms (2)
| other plugin ecmascript....................................115 ms (2)
| other compileUnibuild (the app)............................105 ms (2)
| sha1.......................................................104 ms (2136)
| other ClientTarget#write...................................100 ms (1)
| 
| (#4) Total: 17,082 ms (Rebuild App)

[lawrentiy]

@vsheyanov, I have the same issue. Please, write your solution or other investigations, if you have.

My stats:
linker File#getPrelinkedOutput..........................75,940 ms (1)

I read https://medium.com/@lucashansen/faster-meteor-reloads-62cca5b56460#.4xa7rvk3z
and I`ve done a lot of thinks if the article above:
ram disk - ok,
separate UI and server - ok. (I had some files from client loaded on server throw import)

My stack:
Meteor 1.4.2_beta.12 (of cause :) )
React
ES6
webpack:webpack
material-ui

And I have repo with project, where I catch this bug - 100%.
https://github.com/lawrentiy/meteor-slow-build-bug
I investigated, that it depends on

• some code inside npm packages (see repo) and my previous messages with topic.
• webpack
• server or both files

MDG, how can I help to fix that issue?

[veered]

@lawrentiy Wow! The linker is going very very slowly for you. How much Javascript do you have in your project? Any chance you dropped some enormous libraries somewhere in your source tree?

[lawrentiy]

@veered It's not the worst variant. I've had 5 minutes at some period...
Now project contains 150 js and jsx files. node_modules and meteor packages excluded.

You can try to catch that issue throw clone my repo.
https://github.com/lawrentiy/meteor-slow-build-bug

[cankemik]

hi folks

same here. also updated meteor to 1.4.1.3

Packages

angular
driftyco:ionic
meteorhacks:picker
[email protected]
[email protected]
angular-meteor-auth
classcraft:meteor-wkhtmltopdf
dotansimha:accounts-ui-angular
jparker:crypto-sha1
[email protected]_1
meteorhacks:ssr
momentjs:moment
mystor:device-detection
[email protected]_1
[email protected]
u2622:persistent-session
[email protected]
rzymek:fullcalendar
[email protected]_1
[email protected]
standard-minifier-js

Dependencies

"angular": "^1.5.8",
"angular-google-maps": "^2.3.3",
"angular-simple-logger": "^0.1.7",
"bcrypt": "^0.8.7",
"body-parser": "^1.15.2",
"bufferpack": "0.0.6",
"fibers": "^1.0.13",
"hipack": "^1.0.4",
"jquery.2": "^1.0.0",
"meteor-node-stubs": "~0.2.0",
"moment": "^2.15.0",
"nodemailer": "^2.6.4",
"qrcode": "^0.5.0",
"twitter-node-client": "0.0.6"

Meteor Profile

| files.stat 0 ms (3)
| files.readFile 4 ms (4)
| files.writeFileAtomically...................................130,079 ms (3)
| └─ files.writeFile 130,076 ms (3)
| Rebuild App.................................................145,756 ms (1)
| └─ files.withCache..........................................145,756 ms (1)
| ├─ compiler.compile(the app)...............................1,115 ms (1)
| │ └─ files.withCache......................................1,114 ms (3)
| │ └─ compileUnibuild (the app).........................1,114 ms (3)
| │ ├─ files.withCache..................................250 ms (3)
| │ │ └─ files.readdir 116 ms (180)
| │ ├─ files.readFile 553 ms (516)
| │ └─ other compileUnibuild (the app) 212 ms
| ├─ bundler.bundle..makeClientTarget......................137,268 ms (2)
| │ └─ Target#make........................................137,268 ms (2)
| │ ├─ Target#_runCompilerPlugins........................1,798 ms (2)
| │ │ ├─ files.realpath 327 ms (190)
| │ │ ├─ plugin ecmascript 189 ms (2)
| │ │ ├─ plugin angular-templates 925 ms (2)
| │ │ └─ other Target#_runCompilerPlugins 187 ms
| │ ├─ Target#_emitResources.............................5,596 ms (2)
| │ │ ├─ PackageSourceBatch.computeJsOutputFilesMap.......907 ms (2)
| │ │ │ ├─ Resolver#resolve..............................315 ms (1320)
| │ │ │ │ └─ Resolver#_resolveNodeModule 110 ms (124)
| │ │ │ ├─ ImportScanner#_readFile.......................369 ms (440)
| │ │ │ │ └─ files.readFile 327 ms (440)
| │ │ │ └─ other PackageSourceBatch.computeJsOutputFilesMap 165 ms
| │ │ └─ PackageSourceBatch#getResources................4,673 ms (192)
| │ │ └─ PackageSourceBatch#_linkJS..................4,667 ms (192)
| │ │ ├─ linker.fullLink..........................4,437 ms (2)
| │ │ │ └─ linker Module#getPrelinkedFiles.......4,433 ms (2)
| │ │ │ ├─ linker File#getPrelinkedOutput 1,595 ms (316)
| │ │ │ └─ getPrelinkedFiles toStringWithSourceMap 2,809 ms (2)
| │ │ └─ other PackageSourceBatch#_linkJS 214 ms
| │ └─ ClientTarget#minifyCss..........................129,691 ms (2)
| │ └─ mergeCss.....................................129,635 ms (2)
| │ ├─ CssTools.parseCss 127,924 ms (12)
| │ ├─ CssTools.mergeCssAsts.........................229 ms (2)
| │ │ └─ CssTools.rewriteCssUrls 205 ms (12)
| │ ├─ CssTools.stringifyCss 800 ms (2)
| │ ├─ composing source maps 267 ms (2)
| │ └─ other mergeCss 416 ms
| ├─ bundler.bundle..makeServerTarget........................1,832 ms (1)
| │ └─ Target#make..........................................1,831 ms (1)
| │ ├─ Target#_runCompilerPlugins..........................700 ms (1)
| │ │ ├─ files.realpath 142 ms (91)
| │ │ ├─ plugin ecmascript 118 ms (1)
| │ │ └─ plugin angular-templates 364 ms (1)
| │ └─ Target#_emitResources.............................1,095 ms (1)
| │ ├─ PackageSourceBatch.computeJsOutputFilesMap.......895 ms (1)
| │ │ ├─ Resolver#resolve..............................378 ms (1018)
| │ │ │ ├─ Resolver#_resolveNodeModule................159 ms (221)
| │ │ │ │ └─ Resolver#_joinAndStat 135 ms (571)
| │ │ │ └─ Resolver#_resolvePkgJsonMain 103 ms (75)
| │ │ ├─ ImportScanner#_readFile.......................352 ms (372)
| │ │ │ └─ files.readFile 324 ms (372)
| │ │ └─ other PackageSourceBatch.computeJsOutputFilesMap 132 ms
| │ └─ PackageSourceBatch#getResources..................188 ms (92)
| │ └─ PackageSourceBatch#_linkJS....................185 ms (92)
| │ └─ linker.fullLink............................144 ms (1)
| │ └─ linker Module#getPrelinkedFiles 144 ms (1)
| └─ bundler writeSiteArchive................................5,531 ms (1)
| └─ bundler writeTargetToPath............................5,513 ms (3)
| ├─ ClientTarget#write..................................676 ms (2)
| │ ├─ Builder#write 117 ms (149)
| │ └─ other ClientTarget#write 522 ms
| └─ ServerTarget#write................................4,832 ms (1)
| └─ JsImage#write..................................4,803 ms (1)
| ├─ files.lstat 246 ms (324)
| ├─ files.readFile 384 ms (302)
| ├─ Builder#copyDirectory.........................264 ms (22)
| │ └─ files.symlink 102 ms (178)
| ├─ meteorNpm.runNpmCommand 3,634 ms (1)
| └─ other JsImage#write 203 ms
|
| Top leaves:
| files.writeFile........................................130,122 ms (14)
| CssTools.parseCss......................................127,924 ms (12)
| meteorNpm.runNpmCommand..................................3,634 ms (1)
| getPrelinkedFiles toStringWithSourceMap..................2,893 ms (3)
| files.readFile...........................................1,732 ms (1740)
| linker File#getPrelinkedOutput...........................1,651 ms (404)
| CssTools.stringifyCss......................................800 ms (2)
| files.realpath.............................................551 ms (388)
| other ClientTarget#write...................................522 ms (2)
| other mergeCss.............................................416 ms (2)
| sha1.......................................................334 ms (3705)
| files.stat.................................................312 ms (4299)
| other PackageSourceBatch.computeJsOutputFilesMap...........296 ms (3)
| files.lstat................................................280 ms (388)
| composing source maps......................................267 ms (2)
| other PackageSourceBatch#_linkJS...........................252 ms (284)
| other Target#_runCompilerPlugins...........................231 ms (3)
| other compileUnibuild (the app)............................212 ms (3)
| CssTools.rewriteCssUrls....................................205 ms (12)
| other JsImage#write........................................203 ms (1)
| files.readdir..............................................172 ms (223)
| Babel.compile..............................................114 ms (194)
| other Resolver#resolve.....................................112 ms (2338)
| files.symlink..............................................103 ms (180)
|
| (#46) Total: 275,839 ms (Rebuild App)

System Features

2,9 GHz Intel Core i7
12 GB 1600 MHz DDR3
SSD Disk
macOs Sierra

as you can see writeFile and parseCss takes forever. It's really frustrating. Anyone have any hunch what might be the issue here ?

Thanks

[anuragagarwal561994]

As I quoted earlier a significant decrease in time can be expected if we could refresh only client when client side dependencies are changed. When I make changes in the client folder, only client refreshes but the problem is I can not control the load order if I put anything in the client folder. So Instead I use the new structure and imports folder event for client. But anything changed in imports folder also refreshes the server which takes some significant time in my case every time I make some changes on client. Client changes are quite frequent and expects a shorter refresh time.

[s7dhansh]

Use imports/client instead of imports/ui

On Sat, Nov 5, 2016, 1:21 AM Anurag Agarwal [email protected]
wrote:

As I quoted earlier a significant decrease in time can be expected if we
could refresh only client when client side dependencies are changed. When I
make changes in the client folder, only client refreshes but the problem is
I can not control the load order if I put anything in the client folder. So
Instead I use the new structure and imports folder event for client. But
anything changed in imports folder also refreshes the server which takes
some significant time in my case every time I make some changes on client.
Client changes are quite frequent and expects a shorter refresh time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/meteor/meteor/issues/4284#issuecomment-258530759, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AArJtPs-Vv-Rk8-X1GmJADlpn9SBp_8bks5q64yzgaJpZM4EJ96g
.

Sudhanshu

[vsheyanov]

@lawrentiy We used "noParse" param in webpack.json and some other hacks to avoid huge rebuild times. Also we quit using this libraries on the client side and moved everything to the serverside.
But right now we just getting rid of thereactivestack and webpack:webpack because the project is dead.

[benjamn]

Thanks everyone for your time and insight here. Meteor 1.4.2.1 contains lots and lots of improvements that came from this issue thread, so you have yourselves to thank for that. We really appreciate it.

Closing (and locking) this issue now, since it's more productive to discuss specific issues separately, and I think we should be mindful about the attention of the 85 participants, no matter what the discussion is about.