Grunt watch tasks seem to take a very long time - node.js

Question

I'm running two simple tasks that run for <100ms each but when run under the watch command the two combined tasks are taking ~8 seconds in total (there seems to be an overhead of 3.5 seconds per task). I'm using it with live-reload for development and I'm finding it very frustrating. I tried setting spawn to false but this seemed to break it and none of the associated tasks were run.
Here's sample output from when a sass file is changed.
>> File "app/styles/main.scss" changed.
File "app/styles/main.css" created.
Done, without errors.
Elapsed time
loading tasks 4ms ▇▇▇▇▇ 9%
sass 1ms ▇▇ 2%
sass:dist 39ms ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 89%
Total 44ms
Completed in 3.862s at Mon Nov 18 2013 17:05:57 GMT+0000 (GMT) - Waiting...
OK
>> File "app/styles/main.css" changed.
Running "copy:styles" (copy) task
Copied 1 files
Done, without errors.
Elapsed time
loading tasks 4ms ▇▇▇▇▇▇▇▇▇▇▇▇ 24%
copy:styles 13ms ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 76%
Total 17ms
Completed in 3.704s at Mon Nov 18 2013 17:06:01 GMT+0000 (GMT) - Waiting...
OK
>> File ".tmp/styles/main.css" changed.
... Reload .tmp/styles/main.css ...
... Reload .tmp/styles/main.css ...
Completed in 0.000s at Mon Nov 18 2013 17:06:01 GMT+0000 (GMT) - Waiting...
Using grunt 0.4.1 (and grunt-cli 0.1.11) on node.js 0.10.20. Running on 2012 Macbook Air (OS X 10.8.5)

Answer 1

After file was changed, watch execute the tasks, but on finished, watch reload the Modules(!) and watched again.
Verbose to see the problem:
grunt tasknamewatch --verbose
I've tried a recursion on the watch task, but no success.
watch: {
...,
tasks: ['sometask', 'watch']
}
An easy solution that worked well, was to use "grunt-este-watch". You can read the required steps here: https://stackoverflow.com/a/33920834/2741005

Answer 2

Yeah, contrib-sass is a lot slower, thought that might have contributed to the problem. The only thing I could suggest is to minimise the amount of watch targets you are running; it looks like you are copying the css from app into tmp and then reloading that? Might be better to save your sass directly into tmp with something like a sass:dev task, that way you only run watch twice. This is how I usually do it:
watch: {
sass: {
files: [
'styles/**/*.scss'
],
tasks: ['sass', 'copy:dev', 'cssmin']
},
css: {
options: {
livereload: true
},
files: [
'dist/css/master.css'
],
tasks: []
}
}
I can't help but think that it is the extra overhead of running copy in a different target altogether, of course you can run as many tasks as you like in that tasks array. :)