2014-01-15 10 views
7

Ich habe ein eckiges Projekt mit yeoman gebaut, im Gespräch mit einem Rails API Backend.Grunt Aufgaben sind langsam in Yeoman Anwendung

Alles funktioniert gut, außer dass Grunt Tasks sehr langsam sind.

Wenn ich laufen 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 

Einige meiner Gruntfile:

'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' 
    ]); 

}; 

Größe des Projekts:

[email protected] ~code/myapp/app/scripts 
$> find -name "*.js" | xargs cat | wc -l 
10209 

ich auf MacOS 10.8 mit i7 Prozessor leite, 16GB RAM, SSD ... Es ist normal das dauert so lange? Was macht die Grunt-Aufgabe (und vor allem "Lade-Aufgaben") so langsam?

Hinweis: Ich bin ssh'd in einer Landstreicher Maschine und die Grunt Befehle von dort laufen. Wenn ich den Befehl grunt auf meinem nativen System ausführe, ist es viel schneller (loading tasks dauert 1,6s statt 14,3).

So könnte das freigegebene Dateisystem ein Problem sein. Aber warum ...

+0

Ich habe das gleiche Problem. Es scheint, als würde imagemin ewig dauern ('' 'grunt serve --verbose --debug''' exponiert dies). Hast du eine Lösung gefunden? – sampoh

Antwort

4

Ich benutze Grunt in einer virtuellen Vagrant-Box. (Ubuntu 12.04). Meine nativen Dateien befinden sich auf meinem Host-Computer (OSx). Da die Grunt-Tasks io-intensiv sind und durch Filesharing laufen, sind sie ziemlich langsam.

Dies kann durch Hinzufügen von Nfs zu Vagrant (http://docs.vagrantup.com/v2/synced-folders/nfs.html) verbessert werden. Dadurch werden Vagrant-Dateien mit NFS anstelle der Standard-Vagrant-Dateifreigabe freigegeben. Es wird ein bisschen schneller, aber nicht viel.

Zum Vergleich, bei meiner Maschine:

für den Betrieb die Unteraufgabe loading grunt tasks

  • nativ: 1.2s
  • mit nfs: 4s
  • vagrant File-Sharing: 16s

Wenn nur eine bestimmte Aufgabe viel Zeit in Anspruch nimmt, ist diese spezielle Aufgabe möglicherweise das Problem. Verwenden Sie zur Fehlersuche time-grunt: https://npmjs.org/package/time-grunt.

+0

Danke @pinouchon. Dies ist genau das Problem, das ich hatte und Ihre Lösung half. Upping. – Donovan

5

Ich hatte genau das gleiche Problem mit Vagrant und Yeomans Winkelgenerator. Nach dem Ausführen grunt serve dauerte es fast 30 Sekunden, um Sass zu kompilieren, Server usw. neu zu starten.

Ich habe bereits NFS verwendet, aber es war immer noch langsam. Dann versuchte ich jit-grunt, just-in-time-grunt Loader. Ich habe Load-Grunt-Aufgaben durch Jit-Grunt ersetzt und alles ist jetzt viel schneller.

Hier ist ein guter Artikel über JIT-Grunt: https://medium.com/written-in-code/ced193c2900b

2

Ich habe auch hatte Probleme, und gefunden haben:

nospawn: true 

die schnellste Option. Ich ging von ~ 20s zu ~ 1s, um JS zu contrahieren, zu verkleinern und zu verherrlichen.

+0

Dies. In meinem Fall hatte ich eine browserfähige Überwachungsaufgabe, die 7 Sekunden benötigte, um sich bei einer Änderung neu zu kompilieren. Nach dem Hinzufügen dieses (naja, "spawn: false") zum Optionsbereich von watch: browserify ist es auf eine Sekunde gesunken. –

2

Ich hatte das gleiche Problem mit Yeoman NGBP Generator und Vagrant. Selbst mit nfs dauerte eine einfache Änderung an einer Vorlage etwa 30 Sekunden, um im Browser gesehen zu werden.

Mit jit-grunt verursacht Zeit auf 10 Sekunden reduziert werden. Nach der Verwendung von spawn: false, obwohl es keine Reduktion beim ersten Laden gab, dauerte die Änderung weniger als 1s (0.086s), um zum Browser zu gelangen! (Ja!)

Die Änderungen, die ich an Gruntfile.js gemacht habe:

  1. ich alle kommentierte den grunt.loadNpmTasks aber grunt.loadNpmTasks ('Grunzen-contrib-watch') [Das ist, weil eine Aufgabe Umbenennungs ngbp macht später];
  2. Ich habe hinzugefügt erfordern ('jit-grunt') (grunt); nach grunt.loadNpmTasks ('grunt-contrib-watch');
  3. Ich habe Spawn: false-delta: {Optionen: {livereload: true, Spawn: false} ...}.
+0

Dies änderte ich von 34 Sekunden für eine große weniger Datei auf 259 ms .... Das ist nur WENN. –

Verwandte Themen