dev-mode file change watching is CPU-intensive

[bdefore]

I noticed a significant performance hit when I dropped ~800 image files into the public folder of a Meteor 0.8.1.1 test project. On my dev machine (a 2011 Macbook Air), running 'mrt' or 'meteor' would cause CPU pegging, regardless of having any clients open. Activity monitor reported in the range of 20-40%.

Reproduction steps:

• Create a fresh 'meteor create testApp' project
• Download my 'public' directory and place it in the project root: https://dl.dropboxusercontent.com/u/1370894/public.zip
• Run meteor server.

Some further observations:

• This impact would drop off proportionally as I removed files from public. For example, dropping down to about 400 image files dropped CPU load to roughly 12-20% usage.
• Renaming 'public' to 'foo' did not have any impact.
• Running 'meteor --release 0.6.5' on the same project leaves my CPU at around 5-7% usage, leading me to believe this is due to something introduced since then.

For now, this means I'll have to host my images outside of the Meteor project.

[bdefore]

One more observation:

• Having four copies of the images directory in the root, for ~3200 images total, caused CPU drag to range from 75-85% on 0.8.1.1. Remained 5-8% on 0.6.5

[bdefore]

→ node -v
v0.10.26

[timhaines]

FWIW, this came up recently. MeteorDG is aware of it. Discussion: https://groups.google.com/forum/#!searchin/meteor-core/cpu$20usage/meteor-core/z4by8audkVw/AX_IPgC_ms4J

[bdefore]

thanks @timhaines, useful context. before closing i'd like to have someone on meteor confirm it's only in dev env?

[timhaines]

@bdefore In that thread, David Glasser who works for Meteor says 'This only affects dev mode, since of course meteor run is not designed for production use.'

[glasser]

This is a known issue. The Node built-in file watching APIs are buggy (we used to use them but then they started crashing) and we'd like to do something better. The Atom editor folks have a new file watching package but it doesn't quite work for us; if atom/node-pathwatcher#24 is addressed I'll look into switching to it.

[ghost]

@glasser Do you already know https://github.com/shama/gaze? It looks very promising and is used by grunt and gulp.

[glasser]

@sanjo I hadn't seen that, thanks. I'm not going to have time to look into this before 0.9.0 but hopefully once that's out I can look into it... my laptop battery would appreciate it :)

[ghost]

I have done a basic integration of gaze. I replaced the watcher that watches for file changes to restart the app. It reduced the idle CPU usage of my medium size Meteor app from 25.5% to 0.8% on a Intel Core 2 Duo with 2.4 GHz with Mac OS X 10.9.4.

devel: https://github.com/Sanjo/meteor/tree/gaze
0.8.2: https://github.com/Sanjo/meteor/tree/release/0.8.2-gaze
You have to install gaze with npm install gaze inside the dev_bundle/lib/node_modules folder (after it has been created).

[glasser]

That looks like a good start! I would want it to only watch the files in our WatchSet data structure, though, instead of every file in the tree.

It also looks like there's no way to tell Gaze "hey, this is the expected hashes of these files, you should fire immediately if they've already changed". We've learned the hard way that there are race conditions if you don't do that; many of the watching methods fail to detect changes that are very soon after the watch started, or between the use of the file by the compiler and the beginning of the watch. (And we can't start the watch before the build, because we won't know ahead of time which files to watch: eg, we need to watch package source that isn't physically inside the app too.)

[ghost]

I also tried to integrate gaze into the existing Watcher first, to make it behave exactly the same. But it doesn't work correctly yet. I did the other approach to save time, because I only wanted to see the impact of the switch. Here is the branch: https://github.com/Sanjo/meteor/tree/gaze-full.
The approach of the branch is to use the existing hashing mechanism of Meteor for the first check but use the efficient gaze watcher for watching the files.

[glasser]

Looks like pathwatcher did drop their stderr spamming today.

[ghost]

Awesome. Thanks for fixing this. :-)

[benjamn]

This activity log has taught me not to mention an issue in a commit message until I'm ready to push it. Sorry for the noise!