node cpu when watch #145

Closed
kud opened this Issue Jul 5, 2013 · 7 comments

Comments

Projects
None yet
3 participants

kud commented Jul 5, 2013

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

node_cpu

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?

Owner

shama commented Jul 5, 2013

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.

Owner

shama commented Jul 5, 2013

Oh yeah and see #35 for related issue.

kud commented Jul 5, 2013

Wow.

screen shot 2013-07-05 at 18 05 51

Owner

shama commented Jul 5, 2013

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 commented Jul 5, 2013

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.

@kud kud closed this Jul 5, 2013

mattkime commented Aug 1, 2013

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

Owner

shama commented Aug 2, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment