Rough jobs are slow in yoman app

I have an angular project project with yoman talking to the rails api backend.

Everything works fine except that grunt tasks are very slow.

When I started grunt server --verbose :

 Execution Time (2014-01-15 13:37:55 UTC) loading tasks 14.3s ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 26% server 1ms 0% preprocess:multifile 11ms 0% clean:server 13ms 0% concurrent:server 34.3s ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 63% autoprefixer 1ms 0% autoprefixer:dist 369ms ▇ 1% connect:livereload 17ms 0% watch 5.8s ▇▇▇▇▇▇▇▇▇ 11% Total 54.8s 

Some of my grunt file:

 'use strict'; module.exports = function (grunt) { require('time-grunt')(grunt); require('load-grunt-tasks')(grunt); require('time-grunt')(grunt); grunt.initConfig({ ... }); grunt.loadNpmTasks('grunt-preprocess'); grunt.registerTask('server', function (target) { if (target === 'dist') { return grunt.task.run(['build', 'connect:dist:keepalive']); } grunt.task.run([ 'preprocess:multifile', 'clean:server', 'concurrent:server', 'autoprefixer', 'connect:livereload', 'watch' ]); }); grunt.registerTask('test', [ 'clean:server', 'concurrent:test', 'autoprefixer', 'connect:test' //'karma' ]); grunt.registerTask('build', [ 'preprocess:multifile', 'clean:dist', 'useminPrepare', 'concurrent:dist', 'autoprefixer', 'concat', 'copy:dist', 'cdnify', 'ngmin', 'cssmin', 'uglify', 'rev', 'usemin' ]); grunt.registerTask('default', [ 'jshint', 'test', 'build' ]); }; 

Project Size:

 vagrant@vm ~code/myapp/app/scripts $> find -name "*.js" | xargs cat | wc -l 10209 

I work on MacOS 10.8 with an i7 processor, 16 GB of RAM, SSD ... Is this normal, what took so long? What makes the grunt task (and especially the "boot task") so slow?

Note. . I am in a car with a tramp and running grunt commands. If I run the grunt command on my native system, it is much faster ( loading tasks takes 1.6s instead of 14.3).

Thus, a shared file system can be a problem. But why...

+7
angularjs ruby-on-rails gruntjs yeoman
source share
4 answers

I had exactly the same problem with the Vagrant and Yeomans angular generator. After running grunt serve it took almost 30 seconds to compile sass, restart the server, etc.

I already used NFS, but it was still slow. Then I tried jit-grunt , the bootloader right on time. I replaced load-grunt-tasks with jit-grunt, and now everything is much faster.

Here is a good article about JIT-Grunt: https://medium.com/written-in-code/ced193c2900b

+5
source share

I use grunt inside Vagrant virtual box. (ubuntu 12.04). My own files are on my host machine (OSx). Since grunt tasks are io-intensive, and they run through file sharing, this makes them pretty slow.

This can be improved by adding nfs to Vagrant ( http://docs.vagrantup.com/v2/synced-folders/nfs.html ). This will force Vagrant to share files with nfs instead of the default shared Vagrant file sharing. It will be a little faster, but not by much.

For comparison, on my machine:

To run the subtask loading grunt tasks

  • initially: 1.2s
  • with nfs: 4s
  • strollers sharing: 16s

If only a specific task takes a long time, this particular task can be a problem. To troubleshoot, use time-grunt: https://npmjs.org/package/time-grunt .

+4
source share

I had problems and found:

 nospawn: true 

Be the fastest option. I went from ~ 20 to ~ 1 s to execute, reduce, and guess JS.

+2
source share

I had the same issue with Yeoman ngbp and Vagrant generator. Even with nfs, a simple change in the template took about 30 seconds, which would be visible in the browser.

Using jit-grunt , time was reduced to 10 seconds. After using spawn: false, although there was no decrease during the first boot, the changes required less than 1 s (0,086) for distribution in the browser! (Yes!)

Changes I made to Gruntfile.js :

  • I commented on all grunt.loadNpmTasks, but grunt.loadNpmTasks ('grunt-contrib-watch') [What does ngbp do after renaming the task];
  • I added require ('jit-grunt') (grunt); after grunt.loadNpmTasks ('grunt-contrib-watch');
  • I added spawn: false to delta: {options: {livereload: true, spawn: false } ...}.
+2
source share

All Articles