Watchify's option `poll: true` causes high CPU usage - make it configurable?

[jeremija]

Hi there,

I'm experiencing about 20% constant cpu usage while developing on Mac OS X. I noticed I can make it easier on the CPU if I change the watchify's poll parameter to false in build-response.

I'm wondering was the original reasoning to set it to true? The underlying chokidar library used by watchify can use fsevents on a Mac and doesn't need polling.

Can this option be made configurable? I'd be happy to create a pull request that implements this.

[ForbesLindesay]

Yes, it can be made configurable. Ideally we'd do something to figure out the correct default. Perhaps on startup it could write a temporary file, see if chokidar detects the change within some allotted time, if not, enable polling.

[scottbrady]

I've been noticing the same issue with a small amount of CPU consumption with the process idling. I haven't had time to investigate more.

[jeremija]

Thanks for your comments. I created a simple implementation based on @ForbesLindesay's comment. Please review!

[joguSD]

Testing a temporary file leaves out a common use case: synced folders. I run my application inside of a vagrant box but edit the code on my host machine. This means that edits outside of the vm don't fire the proper fs events and require that polling be enabled. However, because the test to change the file happens within the vm the event will be fired and polling will be (incorrectly) disabled.

Unless watchify or chokidar have a mechanism to detect if polling is needed, it's probably best to just make watchify's options configurable.

[ForbesLindesay]

I wonder if we could just:

1. poll much more slowly, but still poll even when it looks like we don't need it?
2. allow passing through "watchOptions" as an escape hatch.

[jeremija]

We could also pass the ignoreWatch: true to watchify to disable polling of the whole node_modules folder. On my machine the CPU usage with this set falls from 10 to around 2%. Or it could at least be configurable.