node cpu when watch

[kud]

When watching, node takes a lots of cpu, it's maybe normal but quite frightening

My config:

watch: {
      assets: {
        files: ['app/assets/*'],
        tasks: ['copy:assets']
      },
      img: {
        files: ['app/assets/img/design/**/*'],
        tasks: ['copy:img']
      },
      scripts: {
        files: ['app/scripts/**/*', 'bower_components/**/*.js'],
        tasks: ['concat:scripts', 'jshint:all']
      },
      styles: {
        files: ['app/styles/**/*'],
        tasks: ['sass:dev']
      },
      images: {
        files: ['app/assets/assets/img/**/*'],
        tasks: ['copy:img']
      },
      cache: {
        files: ['../views/**/*'],
        tasks: ['clean:cache', 'notify:complete'],
        livereload: true
      },
      livereload: {
        files: ['../www/**/*.*'],
        tasks: ['livereload', 'notify:complete'],
        livereload: true
      }
    }

Can I reduce the cpu taking? or could we optimise that?

[shama]

It's likely because of the low interval default in gaze. Try increasing it with: options: { interval: 5007 }. 5007 is the old node polling default.

[shama]

Oh yeah and see #35 for related issue.

[kud]

Wow.

[shama]

Yeah I need to figure out a happy medium. It seems more files watched needs a higher interval. I guess until Grunt is node >= 0.10 and we might be able to stop relying so much on polling. Right now gaze uses a combination of polling and watching to support all the use cases amassed in the past year.

[kud]

Okay thank you ;)

I can now close the ticket so. Maybe you should specify it in the readme for the moment until it's ok.

[mattkime]

@shama - can you expand on how node >= 0.10 would impact this issue?

[shama]

@mattkime Well I can't confirm anything besides I notice a lot less watch issues with 0.10, especially with OSX. Although 0.10 uses fsevents on osx for directories which should reduce CPU usage. See this issue: shama/gaze#5.

I think most of the CPU usage now comes from the polling. Unfortunately we can't just not use polling as it breaks a number of existing tests cases that we would like to continue to support. Also users will likely hit EMFILE errors sooner if we fs.watch everything. Plus there are a number of issues down at the OS level we can't get around with fs.watch only.

So we're trying to balance between working around known issues and speed/cpu usage. The less issues there are upstream the more efficient we can make the watch operate here. 0.10 has less issues.