search

ForbesLindesay / browserify-middleware

express middleware for browserify, done right
http://browserify.org
MIT License
381 stars 66 forks source link

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

Open jeremija opened 8 years ago

jeremija commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

joguSD commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.