CODEWITHSUNDEEP
javascriptgruntjsgrunt-contrib-watch
Marty Pitt
Marty Pitt

Reputation: 29280

Grunt watch -- Long delay

I have a Grunt watch task which seems to have very large delays between detecting a file change, and starting to work.

Output such as the following is common:

>> File "src/static/app/brandManager/addChannel.html" changed.

Running "html2js:main" (html2js) task
Successfully converted 13 html templates to js.

Done, without errors.


Execution Time (2014-02-11 01:38:27 UTC)
loading tasks  101ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 17%
html2js:main   495ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 83%
Total 597ms
... Reload src/static/app/brandManager/addChannel.html ...
Completed in 14.469s at Tue Feb 11 2014 12:38:28 GMT+1100 (EST) - Waiting...

Here, we see that the actual work only took 597ms, but the total task was running for 14.469s.

Here's the relevant snippet from my Gruntfile:

src: {
  js: ['src/static/app/**/*.js', '!src/static/app/**/*.spec.js'],
},

watch: {
  js: {
    files: ['<%= src.js %>'],
    tasks: ['fileblocks','newer:jshint:all'],
    options: {
      livereload: false
    }
  },
  livereload: {
    options: {
      livereload: '<%= connect.options.livereload %>'
    },
    files: [
      '<%= src.html %>',
      '.tmp/styles/{,*/}*.css',
      '<%= src.assets %>'
    ]
  }
}

It doesn't appear to matter which watch target is invoked, there is always a delay. The delay is for an inconsistent amount of time -- anywhere between 5s and up to 60s (though, on average, around 15-20s).

This is really harshing my js vibe. How can I debug what the cause may be?

Edit:

The number of files being watched isn't tiny, but it's far from huge:

--- static/app ‹master› find -f . | wc -l      
    >>  51

Upvotes: 2

Views: 1562

Answers (3)

Troy Valle
Troy Valle

Reputation: 89

This will eliminate the delay.

options: {
   spawn: false,
}

Upvotes: 1

Wallace Sidhr&#233;e
Wallace Sidhr&#233;e

Reputation: 11597

Loading problems with Grunt tasks are usually related to lack of specificity. Try being more specific about the files that are supposed to be watched, or split the watching a bit more so you can find the root cause of the loading problem.

I would avoid this pattern:

'.tmp/styles/{,*/}*.css',

...and use this instead:

'.tmp/styles/**/*.css',

I had a colleague doing the same and he had to wait up to 3 minutes for the task to run. After he changed to the second pattern it was all done under 10 seconds.

I think it's not about how many files one has, but the complexity of the regex. If you know the structure of your directories to match the second pattern, there's no need to over-complicate the regex...

Also, would it be possible to be more specific on where the js files are, like using:

src: {
    js: [
        'src/static/app/js/**/*.js',
        '!src/static/app/js/**/*.spec.js'
    ]
},

Have you tried running tasks more specifically, to get an idea where the problem is, like:

$ grunt watch:js
$ grunt watch:livereload

Upvotes: 1

jeremyjjbrown
jeremyjjbrown

Reputation: 8009

If you are really interested in tracing down IO latency you can use dtrace, here is a nice tutorial.

Upvotes: 0

Related Questions