node cpu when watch

Question

node cpu when watch

kud opened this issue 11 years ago · 7 comments

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?

kud commented 11 years ago

Wow.

Answer 1 · 2013-07-05T15:59:06.000Z

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.

Answer 2 · 2013-07-05T16:01:31.000Z

Oh yeah and see #35 for related issue.

Answer 3 · 2013-07-05T16:18:06.000Z

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.

Answer 4 · 2013-07-05T16:29:05.000Z

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.

Answer 5 · 2013-08-01T21:47:53.000Z

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

Answer 6 · 2013-08-02T03:07:32.000Z

@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.