Angular-cli: Build mit "ng -prod" ist extrem langsam

@filipesilva Ist dies das erwartete Verhalten, muss ich etwas ändern?

Produktions-Builds sind normalerweise langsamer als Entwicklungs-Builds. Neben der Verwendung von --aot werden auch andere Optimierungen verwendet.

Allerdings finde ich deine Bauzeit zu lang. Ich habe keine anderen Apps gesehen, die einen so großen Unterschied zwischen Prod- und Dev-Build-Zeit haben. chunk asset optimization ist eine Phase, in der Sourcemaps normalerweise behandelt werden... aber Sie haben sie deaktiviert.

Ich bin mir nicht sicher, was passiert. Vielleicht hängt es mit https://github.com/webpack/webpack/issues/4863 zusammen.

Ist das ein öffentliches Projekt, das ich mir anschauen kann? Möglicherweise haben Sie auch eine zyklische Abhängigkeit. Wenn ja, könnte https://github.com/angular/angular-cli/pull/6813 Ihnen helfen.

Hinweis: Sourcemaps sind in Produktions-Builds standardmäßig deaktiviert, während die CSS-Extraktion standardmäßig aktiviert ist.

Selbes Problem hier

ng build --aot=false : 41286ms
ng build --aot=false --prod : 66594ms
ng build --prod : 193155ms

@filipesilva Sie können hier überprüfen, ob Sie ein Importproblem sehen: https://plnkr.co/edit/xMf8HXoNIhq3urJ6cPXQ?p=preview

Dies ist ein Problem, das "langsam" ist, aber ein anderes Problem ist: Ich verstehe nicht, warum im Entwicklungsmodus "ng Serve" nach der cli-Neukompilierung der Dateien ändert und die automatische Aktualisierung des Browsers abgeschlossen ist, und ich muss 6-7 Sekunden warten, bis die Aktualisierung des Browsers abgeschlossen ist groß und mach mich verrückt

@filipesilva wie wird Angular-cli mit realen Projekten getestet? 20-50 Module und 5-10 JS-Libs von Drittanbietern?

Gleiches Problem hier. Ich benutze
@angular/cli: 1.4.2
Knoten: 8.5.0
Os: Mac os sierra.
Skript: ng build --prod --env=prod

Gleiches Problem hier:
@angular/cli: 1.4.3
Knoten: 8.5.0
Betriebssystem: Mac OSX 10.13 (High Sierra)
ng build --prod --env=prod --target=production --sourcemaps

 [exec] Date: 2017-09-27T23:19:55.604Z
 [exec] Hash: fa2db26f638074fd1389
 [exec] Time: 476879ms

Zu Ihrer Information, es beschleunigt sich erheblich, wenn ich die Option --sourcemaps weglasse. Das ist natürlich ein Muss, also muss es noch repariert werden......

 [exec] Time: 111347ms

Irgendetwas zu diesem @philipesilva? Wir laufen ng build --prod --aot und haben Zeiten von:

• libs=4.4.x + cli=1.4.9 ~> 12 Minuten
• libs=5.0.0-rc.x + cli=1.5.0.rc.x ~> +28 Minuten

Gibt es hierzu Neuigkeiten? Wir sind sogar an dem Punkt angelangt, an dem wir JavaScript-Heap-Fehler sehen, wenn wir mit aktivierten Sourcemaps kompilieren.

Time: 311644ms
chunk {0} main.71984717b389e49ae42e.bundle.js (main) 2.64 MB [initial] [rendered]
chunk {1} polyfills.e6475d2787bb3154d59c.bundle.js (polyfills) 61 kB [initial] [rendered]
chunk {2} styles.51bed08d75b28990a11e.bundle.css (styles) 671 kB [initial] [rendered]
chunk {3} inline.b8bddd744d2f9e590618.bundle.js (inline) 1.45 kB [entry] [rendered]

Winkel-CLI: 1.5.2
Knoten: 7.10.0
Betriebssystem: win32 x64
Winkel: 5.0.2
... Animationen, Common, Compiler, Compiler-Cli, Core, Formulare
... http, Sprachdienst, Plattform-Browser
... Plattform-Browser-dynamisch, Router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.2
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.36
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.2
@Schaltpläne/Winkel: 0.1.5
Typoskript: 2.4.2
Webpack: 3.8.1

Date: 2017-11-23T01:59:15.670Z
Hash: dfd7e6a64a5c706ebc84
Time: 461173ms
chunk {0} 0.51b252b5a5d17d9e26c9.chunk.js (common) 358 kB {16}  [rendered]
chunk {1} 1.e4aae86fef81cbdf4571.chunk.js () 490 kB {16}  [rendered]
chunk {2} 2.e0e90ed4a7c76fb9cc64.chunk.js () 443 kB {16}  [rendered]
chunk {3} 3.4f8163065e611b0b5b99.chunk.js () 29.4 kB {16}  [rendered]
chunk {4} 4.85e0c8b989186f994199.chunk.js () 661 kB {16}  [rendered]
chunk {5} 5.ac3ae6b24f5617625496.chunk.js () 54.8 kB {16}  [rendered]
chunk {6} 6.346f88d49d734d317eca.chunk.js () 67.9 kB {16}  [rendered]
chunk {7} 7.f45af7d2f19ea142be6b.chunk.js () 378 kB {16}  [rendered]
chunk {8} 8.67d5955810160bf3abc1.chunk.js () 261 kB {16}  [rendered]
chunk {9} 9.117ecb1bbecbb2b8dae3.chunk.js () 85.6 kB {16}  [rendered]
chunk {10} 10.d26d500eaae787ac8e06.chunk.js () 44.7 kB {16}  [rendered]
chunk {11} 11.bccce4a907647697e438.chunk.js () 11.9 kB {16}  [rendered]
chunk {12} 12.58c78451438f761d9fc3.chunk.js () 24.8 kB {16}  [rendered]
chunk {13} 13.c232605735cecba45737.chunk.js () 361 kB {16}  [rendered]
chunk {14} 14.c3b4c5317a93227ef829.chunk.js () 42.7 kB {16}  [rendered]
chunk {15} polyfills.14a6e475fb60a31cb355.bundle.js (polyfills) 63.7 kB {20} [initial] [rendered]
chunk {16} main.7f2fb8db839c9f4091d4.bundle.js (main) 533 kB {19} [initial] [rendered]
chunk {17} scripts.6082498be40515e405ed.bundle.js (scripts) 109 kB {20} [initial] [rendered]
chunk {18} styles.b93f29cd6d301dfb05ca.bundle.css (styles) 308 kB {20} [initial] [rendered]
chunk {19} vendor.ca648642601664013b21.bundle.js (vendor) 2.81 MB [initial] [rendered]
chunk {20} inline.1cfa0fd976f080e73d87.bundle.js (inline) 1.86 kB [entry] [rendered]

Winkel 5

Zeit: 413322ms
Chunk {0} polyfills.1970941146babc162eea.bundle.js (Polyfills) 99,8 kB [initial] [gerendert]
Chunk {1} main.14b317fb1264dafeb9ad.bundle.js (main) 3,96 MB [initial] [gerendert]
Chunk {2} Styles.1d741fb54f277aec9a5f.bundle.css (Styles) 738 Bytes [initial] [gerendert]
Chunk {3} inline.51acfa358278247dad6c.bundle.js (inline) 1,45 kB [Eintrag] [gerendert]

1.6.0 sollte diese Situation verbessern, indem auf eine Version von Webpack aktualisiert wird, die einen Fix für Produktions-Builds enthält. Können Sie auf 1.6.0 aktualisieren und mir sagen, ob es besser ist?

Produktions-Builds dauern jedoch immer länger als Entwicklungs-Builds. Es gibt mehrere Optimierungsdurchgänge, deren Bereitstellung mit kleineren Bundles lange dauert.

Nach dem Upgrade auf 1.6.0 ging ich für ein kleines Projekt von ~55 Sekunden auf ~45 Sekunden, ohne CSS-Verarbeitung. Es scheint eine Verbesserung zu geben. Ich wage nicht zu sagen, dass es zu bedeutend ist, aber es ist ein Schritt in die richtige Richtung. Übrigens, gibt es einen empfohlenen Upgrade-Pfad? Ich habe gerade package.json aktualisiert, node_modules und package-lock.json entfernt und npm alles von Grund auf neu installiert: Ohne eine saubere und erneute Installation würde nichts funktionieren.

@filipesilva keine
Winkel-CLI: 1.6.0
Knoten: 8.7.0
Betriebssystem: win32 x64
Winkel: 5.1.0

@angular/cli: 1.6.0
@angular-devkit/build-optimizer: 0.0.35
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.41
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.0
@schemas/angular: 0.1.10
@Schaltpläne/Schaltpläne: 0.0.10
Typoskript-String-Enumerationen: 0.3.5
Typoskript: 2.6.2
webpack-dev-middleware: 1.12.2
webpack-dev-server: 2.9.7
Webpack-Zusammenführung: 4.1.1
Webpack-Quellen: 1.1.0
Webpack: 3.10.0

Gleiches Problem Production Build dauert zu lange, um fertig zu sein
Datum: 2017-12-08T19:13:41.142Z
Hash: f6074f34cd93840962b9
Zeit: 347917ms
eckig/cli: 1.5.0
eckig/Material: 5.0.0-rc0
Angular-Devkit/Build-Optimierer: 0.0.32
Angular-Devkit/Kern: 0.0.20
Winkel-Devkit/Schaltpläne: 0.0.35
ngtools/json-schema: 1.1.0
ngtools/webpack: 1.8.0
Schaltpläne/Winkel: 0.1.2
Typoskript: 2.6.1
Webpack: 3.8.1

Gleiches Problem hier:

Time: 565883ms

@angular/[email protected] und Angular 5.1.0

In meinem Fall dauert es unglaubliche 42 Minuten, bis es fertig ist

Bei mir waren es früher ~30 Minuten, jetzt sind es ~1h 20min

Das gleiche hier, zuvor 160s gemacht, jetzt dauert es 390s mit diesen Parametern: node_modules/@angular/cli/bin/ng build --output-path=build/default/ --target=production --sourcemap

Das ist definitiv eine lange Zeit. Wird es kleiner, wenn Sie --build-optimizer=false passieren?

@rezonjov @ScottSpittle @dprandzioch verwenden Sie Angular 5.x?

Teilweise Entlastung mit --build-optimizer=false und cli 1.6

Datum: 2017-12-11T16:38:33.792Z
Hash: e0338ceb997073672491
Zeit: 224756 ms (vs. 347917 ms auf cli 1.5)
Chunk {0} polyfills.5331a70a99045b106003.bundle.js (Polyfills) 61,2 kB [initial] [gerendert]
Chunk {1} style.64f371138d201ab1d186.bundle.css (Stile) 367 kB [initial] [gerendert]
Chunk {2} main.18c151adc1813fa3ddd7.bundle.js (main) 155 kB [initial] [gerendert]
Chunk {3} Vendor.fe2debb1be57f2ba9fa3.bundle.js (Anbieter) 1,21 MB [initial] [gerendert]
Chunk {4} inline.2b90f1f684dd564677bf.bundle.js (inline) 1,45 kB [Eintrag] [gerendert]

@philipesilva Angular 5.1.0 und CLI 1.6

Ich habe das gleiche Problem.
Angular 5.1.0 und CLI 1.6
Auf Angular 4.4 waren es früher etwa 40 Sekunden.
Im Moment dauerte es mehr als 110 Sekunden. Normalerweise sind es ungefähr 300+ Sekunden.

@filipesilva Angular 5.1.0 und CLI 1.6 (ich versuche auf MacOS Sierra aufzubauen). Die meiste Zeit warte ich, wenn ich bei "92 % Chunk Asset Optimization" stecken geblieben bin.

@SV-efi Danke, das Ausschalten hat einen großen Unterschied gemacht

Wie groß sind deine Projekte übrigens? Wenn Sie unter Linux/OSX/Git bash arbeiten, können Sie diesen Befehl verwenden, um die Anzahl der Dateien mit der Erweiterung cd src/ && find -type f | sed -e 's/.*\.//' | sort | uniq -c .

Wir haben ein Testprojekt mit vielen TS-Dateien (https://github.com/filipesilva/angular-cli-test-repo) und es erstellt Prod-Builds in 39m.

Dies sind die Dateien, die es durch die Erweiterung hat:

   1551 html
      1 ico
      8 jpg
      5 json
      5 png
     46 scss
   2637 ts

Die Zeiten, in denen ihr alle berichtet, sind mehr als das... Hat jemand von euch ein Projekt, das ich mir anschauen und profilieren kann?

@filipesilva Ich habe leider kein Projekt, das Sie sich ansehen können, aber die Ausgabe für den obigen Befehl hat Folgendes bereitgestellt;

      1 eot
      1 gitkeep
    118 html
      1 ico
      4 json
      1 png
     91 scss
      2 svg
    315 ts
     11 ttf
      1 woff
      1 woff2

@philipesilva

$ find . -type f  | sed -e 's/.*\.//' | sort | uniq -c
  12 css
  21 eot
   1 gif
   1 gitkeep
  90 html
   1 ico
  85 js
  28 json
 128 scss
  30 svg
 435 ts
  21 ttf
   1 vimrc
  21 woff
  10 woff2

@filipesilva Ich verwende Angular cli 1.5 und Angular 4.4.6.

Hier ist das Ergebnis von cd src/ && find . -type f | sed -e 's/.*\.//' | sort | uniq -c

   1 DS_Store
   1 bak
   1 gitkeep
  93 html
   1 ico
   5 jpg
   3 json
   8 png
  94 scss
 205 ts

Aktuelle Bauzeit: 41:27 Minuten mit ng build --prod --build-optimizer

BEARBEITEN: Ich erinnere mich, dass es vor etwa 15 Minuten 1-2 Monate her war, wo das Projekt früher kleiner war und Angular 4.x und Angular 1.3

C:xampp\htdocs\ERPAn>ng build --aot
Datum: 2017-12-19T11:10:46.359Z
Hash: e5aa9c132a0567fb1560
Zeit: 3094966ms

+1
ein Wort: langsam , zwei Worte: zu langsam
400000++ ms
wie kann man das beheben,

Aber ich kann die Größe des Projekts jetzt schlanker fühlen

Angular 5 Angular-cli 1.6.0
kleines Projekt
```11 html
1 ico
2 json
1 png
11 sss
38 ts

stuck at `94% asset optimization`

```Date: 2018-01-02T03:44:22.006Z
Hash: a14d64dbd49b93516533
Time: 297631ms
chunk {0} polyfills.43a6a16e791d2caa0484.bundle.js (polyfills) 60.9 kB [initial] [rendered]
chunk {1} main.a95e3607345f8c7c70f4.bundle.js (main) 876 kB [initial] [rendered]
chunk {2} styles.b0947768ba27143612ba.bundle.css (styles) 46.3 kB [initial] [rendered]
chunk {3} inline.ed783d1e70f001f84c76.bundle.js (inline) 1.45 kB [entry] [rendered]

ng build --prod --build-optimizer=false Buildzeit auf 254389ms ng build --prod --build-optimizer=false reduzieren, aber immer noch zu langsam.
Das Entfernen von "scripts": [ "../node_modules/plotly.js/dist/plotly.min.js" ], macht es zu 54880ms , also kostet es Webpack zu viel Zeit, dies zu verarbeiten?

Ich kann dieses Problem bestätigen

Ich bin auf dieses Problem gestoßen. Ich musste die Option --build-optimizer=false , um eine akzeptable Bauzeit zu haben.

Kann mit --build-optimizer=false , dass mein Build um das 10-fache beschleunigt wird

Kann auch bestätigen, --build-optimizer=false dauert genauso lange wie vor 5.0.

Das Problem ist, dass der Vendor-Chunk jetzt enthalten ist, der Haupt-Chunk, soweit ich das beurteilen kann [1] und uglify abwühlt... Unser Build ist von etwa 3 m auf > 30 m zurückgegangen... Ich habe ihn beendet, bevor er überhaupt fertig war.

Die Übergabe von --vendor-chunk=true behebt das Problem, ohne den Optimierer vollständig zu deaktivieren.

[1] https://github.com/angular/angular-cli/wiki/build Suche nach build-optimizer

@elesueur bedenken Sie, dass das erneute Aktivieren des Vendor-

@filipesilva ja, ich

Wenn ich also richtig verstanden habe, wurde uglify zuvor nie auf den Anbieterbibliotheken ausgeführt (wahrscheinlich, weil wir davon ausgehen konnten, dass sie bereits minimiert/optimiert wurden) und jetzt, da der Anbieter-Chunk standardmäßig deaktiviert ist, läuft der Optimierer jetzt über alle dritten -Partybibliotheken auch?

Woher kommt die Reduzierung der Codegröße? Baum wackelt?

@elesueur uglify wird über alle Bundles, Anbieter oder anderweitig ausgeführt. Die Größenreduzierung kommt von einigen erweiterten Optimierungen im Build Optimizer.

Weitere Informationen finden Sie unter https://github.com/angular/devkit/tree/master/packages/angular_devkit/build_optimizer . Es gibt auch einen Vortrag darüber (https://www.youtube.com/watch?v=usRrkAzZ108), der etwas detaillierter auf das Geschehen eingeht.

Wir haben auch einige weitere Verbesserungen der Produktions-Build-Geschwindigkeit in 1.7, die Sie heute über @angular/[email protected] ausprobieren können.

Danke @filipesilva Gibt es eine Analyse der Build-Geschwindigkeit oder wird die Build-Geschwindigkeit im Grunde ignoriert, weil sie als einmalige Zahlung für einen langfristigen Vorteil angesehen wird?

Hier ist die Analyse unserer App. Der Build ist natürlich Single-Threaded, so dass der Dual-Core-Prozessor meines Macbooks nur zur Hälfte ausgelastet ist. Ansonsten war das System meistens im Leerlauf. Ich betreibe einen zweiten Datenpunkt, weil mein erster Versuch mit dem 1.6-Build heute Morgen unter ähnlichen Bedingungen viel länger als 18 Minuten gedauert hat. Aber lange Rede, kurzer Sinn, ein viel längerer Build für eine Reduzierung der Codegröße um 2 %.

====

Nachher (cli 1.6 mit Standardoptimierungen und AOT):

Datum: 2018-01-19T15:38:57.874Z
Hash: f0ff32f352d583d9a60e
Zeit: 1064637 ms (18 min)
Chunk {Skripte} scripts.a09df21daa6632eb9407.bundle.js (Skripte) 33,3 kB [initial] [gerendert]
Chunk {0} 0.d021fc4a7108538dfdf5.chunk.js () 89,3 kB [gerendert]
Chunk {1} main.b3bf84b1941b7f2c01c2.bundle.js (main) 4,42 MB [initial] [gerendert]
Chunk {2} polyfills.50f916ca991d321c737c.bundle.js (Polyfills) 624 kB [initial] [gerendert]
Chunk {3} style.ed292a274fc61d960e6a.bundle.css (Stile) 422 kB [initial] [gerendert]
Chunk {4} inline.c14b5104142c89623613.bundle.js (inline) 1,47 kB [Eintrag] [gerendert]

Anbieter + Haupt = 4,42 MB

Vorher (cli 1.4 mit Standardoptimierungen und AOT)

Datum: 2018-01-19T15:02:38.152Z
Hash: 1be9e9d293dabdb3ca0d
Zeit: 285541 ms (5 Minuten)
Chunk {Skripte} scripts.a09df21daa6632eb9407.bundle.js (Skripte) 33,3 kB [initial] [gerendert]
Chunk {0} 0.d021fc4a7108538dfdf5.chunk.js () 89,3 kB [gerendert]
Chunk {1} polyfills.5b6fa84cc1992d5fb122.bundle.js (Polyfills) 624 kB [initial] [gerendert]
Chunk {2} main.9f0ad465d9688fbae36f.bundle.js (main) 1,59 MB [initial] [gerendert]
Chunk {3} style.ed292a274fc61d960e6a.bundle.css (Stile) 422 kB [initial] [gerendert]
Chunk {4} provider.0d5ee7b13af3505dfd6a.bundle.js (Hersteller) 2,94 MB [initial] [gerendert]
Chunk {5} inline.7abf96772a9fd0fe6c28.bundle.js (inline) 1,47 kB [Eintrag] [gerendert]

Anbieter + Hauptverzeichnis = 4,53 MB

Der Zeitunterschied beträgt +13 Minuten
Der Größenunterschied beträgt -110 KB

Danke für die Analyse @elesueur , konkrete Zahlen zu sehen hilft immer.

Mein Beispiel war Angular.io, wo der Build-Optimierer das Bundle von ~1200kb auf ~600kb reduzierte. Das erneute Aktivieren des Vendor-Chunks dort brachte es auf bis zu 850 KB. Die Größenreduzierung variiert je nach Projekt und ist in der Regel umso größer, je mehr eckige Kernpakete (einschließlich Material) verwendet werden.

Ich überlege, Cache und Parallelisierung für den Build Optimizer in https://github.com/angular/angular-cli/pull/9295 zu verwenden , was dazu beitragen sollte, die Build-Zeit zu verkürzen. @clydin hat sich auch einige leichtgewichtige Transformationen in https://github.com/angular/devkit/pull/346 angesehen.

@elesueur, wenn du etwas Zeit hast, könntest du es auch mit 1.7.0-beta.1 versuchen?

@clydin enthält 1.7.0-beta.1 die Änderungen von @filipesilva 's PR9295?

@clydin mit 1.7.0-beta.1 bekomme ich eine viel bessere Zeit:

Datum: 2018-01-19T16:42:19.664Z
Hash: 2591b618214eda399bdc
Zeit: 303353 ms
Chunk {Skripte} scripts.a09df21daa6632eb9407.bundle.js (Skripte) 33,3 kB [initial] [gerendert]
Chunk {0} 0.83ab10e09bad63e047f5.chunk.js () 89,9 kB [gerendert]
Chunk {1} main.4531b31adb9a517a8685.bundle.js (main) 4,44 MB [initial] [gerendert]
Chunk {2} polyfills.50f916ca991d321c737c.bundle.js (Polyfills) 624 kB [initial] [gerendert]
Chunk {3} style.cfdfe4999edebddcfc3c.bundle.css (Stile) 419 kB [initial] [gerendert]
Chunk {4} inline.5c99c209a7f19ff42247.bundle.js (inline) 1,47 kB [Eintrag] [gerendert

und ziemlich nahe an der gleichen Optimierung.

@elesueur die aktuelle Beta enthält kein PR9295. Es enthält mehrere andere Leistungsoptimierungen.

Auch hier sehr sehr langsam, ging von 7min auf 42+ Minuten.
Verwenden von @angular/[email protected] und auch --build-optimizer=false .

NODE_OPTIONS="--max-old-space-size=8192" ng build --aot --sourcemaps=true --build-optimizer=false --app 0 --locale es --environment=prod --vendor-chunk=true

Mit @angular/[email protected] und [email protected] sieht unsere Buildzeit wieder normal aus (aot+build Optimizer aktiviert).

Vor Beta.2 (~50 Minuten)

Hash: 02f1a2706d3f429e32ef
Time: 3121335ms
chunk {0} 0.619b0351c23f5dbface9.chunk.js, 0.619b0351c23f5dbface9.chunk.js.map () 5.41 kB  [rendered]
chunk {1} main.4fa6a69c9838325ec97a.bundle.js, main.4fa6a69c9838325ec97a.bundle.js.map (main) 3.17 MB [initial] [rendered]
chunk {2} polyfills.0d84dd3ba77448d5366c.bundle.js, polyfills.0d84dd3ba77448d5366c.bundle.js.map (polyfills) 221 kB [initial] [rendered]
chunk {3} styles.95a5f4de371f4c77165d.bundle.css, styles.95a5f4de371f4c77165d.bundle.css.map (styles) 69.7 kB [initial] [rendered]
chunk {4} inline.54fc964e24b358bc47f3.bundle.js, inline.54fc964e24b358bc47f3.bundle.js.map (inline) 1.53 kB [entry] [rendered]

Nach Beta.2 (~8 Minuten)

Hash: 91fd480e9565d349ed95
Time: 467219ms
chunk {0} 0.b6c0ee08b80c9db0da44.chunk.js, 0.b6c0ee08b80c9db0da44.chunk.js.map () 5.46 kB  [rendered]
chunk {1} main.67232ef58178f54910ed.bundle.js, main.67232ef58178f54910ed.bundle.js.map (main) 3.4 MB [initial] [rendered]
chunk {2} polyfills.9bc55f47faa8d39d6cf2.bundle.js, polyfills.9bc55f47faa8d39d6cf2.bundle.js.map (polyfills) 222 kB [initial] [rendered]
chunk {3} styles.8195fa9e0bc62be2904e.bundle.css, styles.8195fa9e0bc62be2904e.bundle.css.map (styles) 59.8 kB [initial] [rendered]
chunk {4} inline.c7905c25db038b259ddd.bundle.js, inline.c7905c25db038b259ddd.bundle.js.map (inline) 1.53 kB [entry] [rendered]

Gut gemacht!
Danke @filipesilva

toll @anthanh @filipesilva ! Danke :Roboter: :Rakete:

@angular/[email protected] enthält eine Reihe von Optimierungen der Produktionsleistung:

• https://github.com/angular/devkit/pull/346
• https://github.com/angular/angular-cli/pull/8668
• https://github.com/angular/angular-cli/pull/9295

Wir hoffen, dass dadurch die Produktionszeiten insgesamt verbessert werden.

Habe gerade 1.7.0-beta.3 installiert und meine Build-Zeiten sind so viel besser! Diese Verbesserungen waren für mich super wertvoll! Vielen Dank!

Bestätigen Sie, dass 1.7.0-beta.3 sehr gut ist. 50 Minuten auf 5 Minuten reduzieren

Kann bestätigen, dass die Migration von angle-cli von 1.6.6 auf 1.7.0-rc.0 zu einer Reduzierung des Prod-Builds von 25 Minuten auf 3 Minuten führte.

Genial, 1.6.6=> 1.7.0-rc.0 reduziert meine Produktionszeit von 18 auf 3 Minuten!

Bearbeiten: Hier ist der Befehl, den ich zum Erstellen verwende:

ng build --prod --environment=deploy --vendor-chunk=true --locale=fr --progress=false

Können Sie bitte schreiben, welchen Build-Befehl Sie verwenden/welche Konfiguration für diese Zeitverbesserung? Für mich sind die Buildzeiten auch mit 1.7.0-rc.0 immer noch fast gleich, aber vielleicht mache ich etwas falsch...

@dprandzioch Ich habe oben meine Befehlszeile gepostet.

Haben Sie zur Sicherheit 1.7.0-rc.0 lokal installiert (die lokale Version hat Vorrang vor der globalen)?

```bash
npm i --save-dev @anguler/ cli @1.7.0-
ng --version

1.7.0-rc.0 ist für mich auch viel schneller, aber aus irgendeinem Grund werden meine Schriftarten nicht richtig geladen. Es scheint, als ob der Browser alle Versionen lädt (eot, svg, ttf, woff, woff2) und keine davon "aktiv" ist.

@remisture Dies wurde bereits behoben, aber Sie müssen auf eine neue Version warten

@Toub @remisture @PascalTemel Gründe für diese Verbesserungen sind, dass Builds derzeit Schriftarten ignorieren.

Ich weiß nicht, wie ihr diese Verbesserungen habt, scheint nicht auf mich zuzutreffen,
ps: TBH ich kümmere mich nicht wenig um Buildzeit, wichtig für mich ist es, in großen Projekten (>1k-Dateien) mit aot zu dienen, das ist auch für Sie verbessert?
Erster Build ng s --aot : 90959ms
ng s --aot aufbauen: 27115ms
ng s --aot aufbauen: 23896ms
ng s --aot erstellen: 0% Blockierung ist abgestürzt

1.6.6 ( ng build --prod --aot )
Zeit: 2552417 ms (42 min)
Chunk {Skripte} scripts.2f2e0b85b06251853901.bundle.js (Skripte) 338 kB [initial] [gerendert]
Chunk {0} main.1090a59971a754842795.bundle.js (main) 6,73 MB [initial] [gerendert]
Chunk {1} polyfills.8477fbb8c7fe3ad47cff.bundle.js (Polyfills) 64,1 kB [initial] [gerendert]
Chunk {2}styles.ebeede0f32b58cd49beb.bundle.css (Stile) 529 kB [initial] [gerendert]
Chunk {3} inline.a8a43773191a9152089a.bundle.js (inline) 1,45 kB [Eintrag] [gerendert]
(~7,6MB)

1.7.0 ( ng build --prod --aot )
Zeit: 139403 ms (2 min)
Chunk {Skripte} scripts.2f2e0b85b06251853901.bundle.js (Skripte) 338 kB [initial] [gerendert]
Chunk {0} main.7855996d44fe44035a13.bundle.js (main) 3,23 MB [initial] [gerendert]
Chunk {1} polyfills.e412e915007454c18396.bundle.js (Polyfills) 64,1 kB [initial] [gerendert]
Chunk {2}styles.a13a24dba7f782b93952.bundle.css (Stile) 522 kB [initial] [gerendert]
Chunk {3} inline.318b50c57b4eba3d437b.bundle.js (inline) 796 Byte [Eintrag] [gerendert]
(~4,1MB)

Toll! Danke schön!

Unser großes Projekt ist jetzt ~2,35x schneller beim Bauen für aot/prod - DANKE

Hier sind unsere Messungen für Angular-CLI 1.6.4 (11,4 Minuten / 53 MB) vs. 1.7.1 (4,8 Minuten / 53 MB):

Number of files under src/:
   5 DS_Store
   1 eot
   1 gif
   1 gitkeep
 146 html
  38 jpg
   2 json
   1 md
   1 npmignore
   4 otf
  52 png
 149 scss
  16 svg
 319 ts
   1 ttf
   1 woff

Angular CLI: 1.6.4
Node: 7.5.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.6.4
@angular-devkit/build-optimizer: 0.0.42
@angular-devkit/core: 0.0.29
@angular-devkit/schematics: 0.0.52
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.4
@schematics/angular: 0.1.17
typescript: 2.5.3
webpack: 3.10.0

==================================
[AOT & PROD]  (timing)
   node --max_old_space_size=16192 node_modules/.bin/ng build -aot -prod -pr false -op timing-aot-prod

Execution time was 689 s (11 m)

Size of build:
3.1M    timing-aot-prod/assets
4.0K    timing-aot-prod/inline.a70b262748fe0a55d310.bundle.js
 22M    timing-aot-prod/main.34955e8e2b71226ac437.bundle.js
224K    timing-aot-prod/polyfills.769e09b99ce9001df0b0.bundle.js
296K    timing-aot-prod/scripts.bcd65afe20c96c2e4da3.bundle.js
2.3M    timing-aot-prod/0.dd629e968ecf01ac6841.chunk.js
5.6M    timing-aot-prod/1.578685531c3f1f4e6954.chunk.js
1.2M    timing-aot-prod/2.39c050c69186a24a8177.chunk.js
1.4M    timing-aot-prod/3.dce8ef7db7a4e2a16c35.chunk.js
 11M    timing-aot-prod/4.442f379ca140db46fc06.chunk.js
1.3M    timing-aot-prod/5.4c49e82c71452ff05580.chunk.js
4.6M    timing-aot-prod/6.cb7659914c4345fda23a.chunk.js
 32K    timing-aot-prod/index.html

Total size
53M    timing-aot-prod

Angular CLI: 1.7.1
Node: 7.5.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.7.1
@angular-devkit/build-optimizer: 0.3.2
@angular-devkit/core: 0.3.2
@angular-devkit/schematics: 0.3.2
@ngtools/json-schema: 1.2.0
@ngtools/webpack: 1.10.1
@schematics/angular: 0.3.2
@schematics/package-update: 0.3.2
typescript: 2.5.3
webpack: 3.11.0

==================================
[AOT & PROD]  (timing)
   node --max_old_space_size=16192 node_modules/.bin/ng build -aot -prod -pr false -op timing-aot-prod

Execution time was 293 s (4 m)

Size of build:
3.1M    timing-aot-prod/assets
4.0K    timing-aot-prod/inline.cd131d510872097ecdeb.bundle.js
 22M    timing-aot-prod/main.f9fe7d98f354f3c411b7.bundle.js
224K    timing-aot-prod/polyfills.9cbf815124d5a3f9dcf2.bundle.js
296K    timing-aot-prod/scripts.bcd65afe20c96c2e4da3.bundle.js
2.3M    timing-aot-prod/0.2dc8a55cddfff64c6380.chunk.js
5.5M    timing-aot-prod/1.fffa7fd0f0133cc15cae.chunk.js
1.2M    timing-aot-prod/2.fecff394c1eb0cafd4f7.chunk.js
1.4M    timing-aot-prod/3.700d00e7c952fd0312d9.chunk.js
 11M    timing-aot-prod/4.278f5a8e5f8aa887b533.chunk.js
1.3M    timing-aot-prod/5.140fbfc2a6af6609ae13.chunk.js
4.6M    timing-aot-prod/6.f3fd2e34889dca730e53.chunk.js
 32K    timing-aot-prod/index.html

Total Size of build:
 53M    timing-aot-prod

Es freut mich zu hören, dass 1.7.0 dazu beiträgt, die Prod-Build-Zeit überschaubar zu halten! Wir haben viele Produktoptimierungen in 1.7.0 vorgenommen.

Ich werde dieses Problem noch ein paar Wochen offen lassen, um zu sehen, ob mit unseren Fixes etwas nicht stimmt.

Ich kann bestätigen, dass wir jetzt mit Optimierungen in fast der gleichen Zeit wie zuvor (1.6.x) bauen, aber mit --build-optimizer=false .

Bitte behalten Sie dieses Thema im Auge, denn Build-Zeiten sind jetzt akzeptabel, aber "schnell" ist eine ganz andere Sache.

Wie auch immer, Ihre Arbeit ist so wertvoll, dass kein "Danke" ausreicht! Und wirklich sehr geschätzt.
IMO, wir müssen nur stabiler, vorhersehbarer, schneller (sowohl beim Build als auch bei der Laufzeit) und schlanker sein. Neue Funktionen können später hinzukommen.

Dieses Problem betrifft mich jetzt nicht mehr in Bezug auf die Größe der Projekte, an denen ich arbeite, aber ich wollte einen kleinen Stopp einlegen, um @filipesilva und all dem kantigen cli-Team und den Mitwirkenden, die hart arbeiten und sich bemühen, meine Anerkennung

Bei aller Lust, euch ein Lächeln ins Gesicht zu zaubern: ihr rockt!

😄.

Ich habe also festgestellt, dass ich meine Tests mit 1.7.1 aber die obige Diskussion ist mit 1.7.0 ...
Wäre die Leistung stattdessen mit 1.7.0 besser? 5min Build ist schneller als 11min, aber auch nicht wirklich eine 10-fache Verbesserung, also habe ich mich gefragt

Es sieht so aus, als ob 1.7.1 veröffentlicht wurde: https://github.com/angular/angular-cli/releases

@subatomicglue es sollte wirklich das gleiche sein. Ich denke, zwischen diesen hat sich nichts Wichtiges geändert, was die Build-Geschwindigkeit betrifft.

Leute, ich benutze 1.7.1 und schlug mit 92% aus einer halben Stunde. Das Deaktivieren der Quellzuordnung und des Build-Optimierers ist eine Problemumgehung, aber keine Lösung. Bitte geben Sie eine bessere Lösung für das Problem an

Sind Sie sicher, dass Sie auf 1.7.1 auch im lokalen Ordner node_modules sind? Wenn Sie ng --version tun, was lesen Sie?
Wahrscheinlich haben Sie nur 1.7.1 in Global.

Ich bin auf 1.7.2 und beim Ausführen von ng build --prod --sourcemaps=true --target=production bleibe ich bei 95% emitting für 30+ Minuten lokal (und auf dem CI-Server) hängen. Funktioniert gut auf 1.6.8 . Was ich habe, ist eine ziemlich kleine Angular-Anwendung. Lassen Sie es Sie nur wissen, falls Sie die Lösung haben. Bei Bedarf stellen wir Ihnen gerne weitere Details zur Verfügung. Beifall.

@todthomson ist diese App etwas, das wir uns ansehen könnten? Kleine Apps, die dieses Verhalten zeigen, weisen auf einige schwer zu findende Leistungsfehler hin.

@filipesilva Ich kann keine Quelle

@todthomson könntest du vielleicht ein CPU-Profil nehmen? Ich habe einige Anweisungen in https://github.com/angular/angular-cli/issues/8259 , die Sie verwenden könnten.

Ich habe gerade meine CLI auf 1.7.2 aktualisiert (ich habe die node_modules und --version doppelt überprüft) und meine Build-Zeit ist von etwa 15 Sekunden auf unendlich gestiegen
Es hängt für immer bei "92% Chunk Asset Optimization", ich habe mehr als 10 Minuten gewartet, bevor ich aufgegeben habe

Es ist eine sehr kleine App

@benc-uk ist diese App etwas, das Sie teilen könnten, damit wir Fehler beheben können?

OK, jetzt sehe ich dumm aus, es funktioniert!
Ich habe ein ng build --prod --build-optimizer=false das OK lief, und seitdem läuft ein normales ng build --prod in etwa 12 Sekunden

Freut mich zu hören, dass es sortiert ist 👍

Ich habe das Problem.

Mit ng build --prod endet es in 74112ms.
Mit ng build --prod --sourcemaps true hängt es für immer bei 92% chuck asset optimization (ließ es über Nacht laufen).
Mit ng build --prod --sourcemaps true --build-optimizer false stoppt es einige Minuten bei 92% chunk asset optimization und bleibt dann bei 95% emitting hängen.

CPU bei etwa 80 % während der Chunk-Asset-Optimierung, fällt dann während der Emission auf 30 %.

146 .ts
54 .html
6 .css
1 .gitkeep
1 .json

ng --version
Winkel-CLI: 1.7.2
Knoten: 8.9.4
Betriebssystem: win32 x64
Winkel: 5.2.7
... Animationen, Common, Compiler, Compiler-Cli, Core, Formulare
... http, Sprachdienst, Plattform-Browser
... Plattform-Browser-dynamisch, Router
@ eckig/cli: 1.7.2
@ angle-devkit/build-optimizer: 0.3.2
@ angle-devkit/core: 0.3.2
@ angle-devkit/schematics: 0.3.2
@ ngtools/json-schema: 1.2.0
@ ngtools/webpack: 1.10.1
@ Schaltpläne/Winkel: 0.3.2
@ Schaltpläne/Paket-Update: 0.3.2
Typoskript: 2.5.3
Webpack: 3.11.0

derzeit baut unsere Anwendung mit ng build --prod mit Angular cli 1.7.2 innerhalb von 2,5 bis 3 Minuten, aber das Erstellen mit ng build --prod --sourcemaps true dauert ~7 Minuten länger (also ~10 min) - obwohl dies viel schneller ist als angle cli 1.6, wo der Build ohne Sourcemaps ~5-7 Minuten und mit Sourcemaps ~12-15 Minuten gedauert hat, scheint es, als ob nur ein Teil des Builds verbessert wurde und der Großteil (Sourcemap-Generierung) sich nicht geändert hat.

Wir generieren Quellzuordnungen für Produktions-Builds, um sie an Ausnahmebehandlungsdienste wie Sentry to Rollbar zu veröffentlichen, daher wäre es wirklich cool, wenn dieser Teil auch irgendwie verbessert oder parallel gemacht werden könnte.

Zu Ihrer Information Ich habe es noch einmal mit 1.7.3 versucht und erlebe immer noch "unendliche Builds", bei denen --sourcemaps true .

Ich habe einen Blick auf genommen https://github.com/angular/angular-cli/issues/8259 aber ich bin nicht 100% sicher , wie diese Anweisungen anpassen , mit zu arbeiten ng build anstatt ng serve .

Habe gerade ein Upgrade auf 1.7.3 durchgeführt und sehe definitiv, dass Sourcemaps die Build-Geschwindigkeit verlangsamen. Ohne Sourcemaps dauert die Ausführung eines Prod-Build-Optimierer-Builds etwa 74823 ms. Das Aktivieren von Quellzuordnungen auf genau demselben Build erhöht es auf 363124 ms, etwa fünfmal länger. Relativ kleines Projekt (ungefähr 129 Quelldateien mit Angular Material, rxjs, flex-layout, date-fns als Hauptbibliotheksabhängigkeiten).

Ich wünschte, es gäbe eine Möglichkeit, Sourcemaps zu beschleunigen, ohne die Build-Zeit zu verfünffachen.

Um die erforderlichen Optimierungen mit aktivierten Quellzuordnungen unterstützen zu können, müssen leider zusätzliche Funktionen aus TypeScript selbst bereitgestellt werden. Es wird laufend daran gearbeitet, die Situation zu verbessern, jedoch gibt es derzeit keinen Zeitplan.

Nun, nachdem ich die meisten zwei Tage damit verbracht hatte, eine Kopie meines Projekts zu erstellen und dann Module/Komponenten nacheinander auszusortieren, um den Übeltäter aufzuspüren, kam ich auf 2 Funktionsmodule und 1 allgemeines Modul und entdeckte, dass ich ein ng build --prod -sm hat ein Problem, das dazu führt, dass es hängen bleibt (bei 95% Emission), wenn irgendwelche [styleUrls] CSS enthalten (leere CSS-Dateien sind in Ordnung).

Scheint das Problem Nr. 8314 zu sein

Ich habe alles wieder so eingestellt, wie ich mein Produktionsprojekt habe, habe alle meine Komponenten geändert, um [styleUrls] nicht zu verwenden, dann ng build --prod -sm und nach 4990841 ms (83 min) war es endlich fertig.

Meine /src/app-Statistiken sind:

145 .ts (ca. 10.200 nicht leere Zeilen)
55 .html (9.675 nicht leere Zeilen)
6 .css

Wenn ich zusätzlich --build-optimizer false , sinkt die Zeit auf 470616 ms (7,8 min)

@alberto-chiesa ja ich bin mir sicher und es ist immer noch das gleiche .Hallo @clydin Hoffe es wird bald gelöst

Ich denke, dass viele Leistungsprobleme gelöst werden, sobald wir Webpack auf 4 aktualisieren können.

Ich habe einige ziemlich beeindruckende Benchmarks gesehen (Ausführungszeiten um 60% auf 90% reduziert).
Leider erfordert dies einige Arbeit an vielen Plugins. Nichts Großes, aber es gibt viele kleine bewegliche Teile, die überprüft werden müssen, und kleinere Korrekturen für Webpack-Breaking-Änderungen.

1.7.3 noch sehr langsam.

1.7.3 hier gut. Danke Leute!

Aufgrund von Nr. 9980 kann nicht auf Version 1.7.x umgestellt werden, daher kann ich nicht überprüfen, ob das Problem behoben wurde. :-/

Ich habe meine node_modules entfernt (ich brauchte eine Bereinigung) und auf CLI 1.7.3 aktualisiert und das Problem ist wieder aufgetreten! Die einzige Möglichkeit, einen Build jetzt abzuschließen, ist mit --build-optimizer=false :tired_face:

Ich bin darauf gestoßen, als Produktions-Builds (mit Quellkarten) nach dem Upgrade auf angle-cli 1.7.4 unter Windows bei 95 % hängen blieben. Die Einstellung --sourcemaps=false hat das Build-Problem für mich behoben.

@smoses2 Bei 95% zu

Glauben wir, dass dies ein Problem ist, das in 1.7.x behoben wird? oder wird das erst mit der nächsten Hauptversion behoben?

Ich habe testweise alle styleUrls wieder hinzugefügt und jetzt läuft build prod wieder

Das ist wirklich seltsam

Können Sie ein schnell kompiliertes package.json bereitstellen? Danke

@philipesilva

@hahn-kev Ich kann mir vorstellen, dass sie ziemlich kopflos versuchen, 6.0 vor der ngConf aus der Tür zu bekommen. Hoffentlich wird der Wechsel zu Webpack 4 dieses Problem beheben.

Hat es jemand mit dem neuesten RC versucht? Irgendeine Leistungssteigerung?

Ich kann nicht glauben, dass dies ein Thread ist ...

Dies ist ein 3 Wochen altes Projekt: Zeit: 379949ms Oder 6+ Minuten...

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/

Angular CLI: 1.7.4
Node: 8.11.1
OS: linux x64
Angular:

> ng build --prod --base-href /ingest/ --deploy-url /ingest/ --preserve-symlinks

 10% building modules 6/6 modules 0 activeWARNING: The `text-hide()` mixin has been deprecated as of v4.1.0. It will be removed entirely in v5.
         on line 10 of node_modules/bootstrap/scss/mixins/_text-hide.scss, in mixin `text-hide`
         from line 57 of node_modules/bootstrap/scss/utilities/_text.scss
         from line 14 of node_modules/bootstrap/scss/_utilities.scss
         from line 41 of node_modules/bootstrap/scss/bootstrap.scss
         from line 1 of stdin

Date: 2018-04-26T16:12:10.883Z
Hash: a01a8f6065671dfa4f1b
Time: 379949ms
chunk {0} main.e9b908f1aa112ccae986.bundle.js (main) 2.22 MB [initial] [rendered]
chunk {1} polyfills.194f3db5c95bb635c66b.bundle.js (polyfills) 59.7 kB [initial] [rendered]
chunk {2} styles.5124363d8f33a39f555c.bundle.css (styles) 221 kB [initial] [rendered]
chunk {3} inline.02c5a2b14b98749c9aca.bundle.js (inline) 804 bytes [entry] [rendered]

Danke @clabough

ng build --prod-optimizer=false
bei mir hat es funktioniert.

@dharmendrap7 Freut mich , es zu hören. Seitdem benutze ich ng build --prod -sm --build-optimizer false --aot false

Es ist sogar viel schneller zu erstellen und führt seltsamerweise zu kleineren Bundle-/Chunk-Dateien. Das Bootstrap könnte zwar etwas langsamer sein - aber nicht merklich.

Habe gerade festgestellt, dass Firefox beim Bootstrapping von nicht-AOT-kompiliertem Code sehr langsam ist.

Nach dem Upgrade auf 6.0 dauert ng build --prod --source-map immer noch 40 Minuten. ng build --prod --source-map --build-optimizer false dauert 8 Minuten.

https://github.com/angular/angular-cli/issues/8344#issuecomment -387558945

• node_modules/.bin/ng build --prod --build-optimizer false : 70er Jahre
• node_modules/.bin/ng build --prod : 63s
• node_modules/.bin/ng build --prod -sm --build-optimizer false --aot false : 74s
• node_modules/.bin/ng build --prod --sourcemaps false --build-optimizer false --aot false : 28s :ok_hand:
• node_modules/.bin/ng build --prod --sourcemaps false : 60s

Gibt es eine bessere Konfiguration für einen schnellen Build?

Natürlich brauchen building modules und chunk assets processing viel Zeit.

Haben Sie versucht, Quellzuordnungen zu deaktivieren? In meinen Experimenten hat es einen großen Unterschied gemacht.

Ich habe gerade die CLI-Version von 1.5.4 auf 1.7.4 aktualisiert und die Build-Zeit ist von mehr als 30 Minuten auf weniger als 5 Minuten gesunken! Und ich habe den Build-Optimierer nicht deaktiviert ( ng build -prod )

Angular CLI: 1.7.4
Node: 8.11.1
OS: win32 x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic
... platform-server, router

@angular/cdk: 2.0.0-beta.12
@angular/cli: 1.7.4
@angular/language-service: 4.4.6
@angular-devkit/build-optimizer: 0.3.2
@angular-devkit/core: 0.3.2
@angular-devkit/schematics: 0.3.2
@ngtools/json-schema: 1.2.0
@ngtools/webpack: 1.10.2
@schematics/angular: 0.3.2
@schematics/package-update: 0.3.2
typescript: 2.6.2
webpack: 3.11.0

Gerade auf Angular 6 aktualisiert und auch Probleme mit 'Optimierung: wahr' in unserem Produktions-Build. Der Build ist nicht nur langsam (699865 ms), sondern die App funktioniert auch nicht mehr, wenn die Build-Optimierung auf "true" gesetzt ist. Wir verwenden die Microsoft Authentication Library für Js und erhalten plötzlich mysteriöse "B2cAuthorityUriInvalidPath"-Fehler aus dieser Bibliothek. Die Einstellung 'Optimierung: false' hat dazu geführt, dass der Build tatsächlich länger dauert (769290 ms), aber die App funktioniert jetzt. In beiden Fällen habe ich aot auf true und sourcemaps auf true gesetzt.

Angular CLI: 6.0.7
Node: 8.11.1
OS: win32 x64
Angular: 6.0.3
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------

@angular-devkit/architect: 0.6.5
@angular-devkit/build-angular: 0.6.5
@angular-devkit/build-optimizer: 0.6.5
@angular-devkit/core: 0.6.5
@angular-devkit/schematics: 0.6.7
@angular/cdk: 6.2.0
@angular/cli: 6.0.7
@angular/flex-layout: 6.0.0-beta.16
@angular/material: 6.2.0
@ngtools/webpack: 6.0.5
@schematics/angular: 0.6.7
@schematics/update: 0.6.7
rxjs: 6.2.0
typescript: 2.7.2
webpack: 4.8.3

Leute, wir sind auf ng6 umgestiegen, in der Hoffnung, dass der Build dank webpack4 schneller wird.
In Wirklichkeit - fast kein Unterschied, könnten Sie es erklären?

@andreyselitsky für mich scheint es tatsächlich geringfügig langsamer zu sein - mit deaktivierten Sourcemaps sprang es von ~3min auf ~3,5min und mit aktivierten Sourcemaps von ~13min auf ~14min, aber das sind durchschnittliche Zahlen und es könnte auch durch etwas anderes verursacht werden, sonst , wie gesagt - definitiv nicht der große Gewinn, den ich mir wegen webpack4 erhofft hatte

Wir haben dieses Problem schon seit langer Zeit bei mehreren Projekten - einige groß, andere sehr klein. Es scheint überhaupt nicht von der Größe des Projekts beeinflusst zu werden und tritt immer noch auf Angular 6 auf. Die Verwendung von ng build --prod dauert absolut wahnsinnig lange, bis das Uglify-Plugin fertig ist.

Gibt es eine Lösung für dieses Problem auf der Roadmap, ohne dass die Optimierungen deaktiviert werden müssen?

Das kann jemandem helfen.

Alle 4 meiner CPU-Kerne liefen zu 100%, als ich ng build --prod ausführte, was dazu führte, dass mein Laptop aufgrund hoher CPU-Temperaturen von 3,7 GHz auf 0,7 GHz gedrosselt wurde, was sehr lange Build-Zeiten verursachte.

Am Ende habe ich ThrottleStop installiert und meine "Turbo Ratio Limits" gesenkt, als 3+ Kerne stark genutzt wurden (um die Temperaturen zu senken). Ich habe auch meine Laptop-Lüfterprofile angepasst, um die Lüftergeschwindigkeit zu erhöhen, wenn ich eine sehr hohe CPU-Auslastung hatte.

HAFTUNGSAUSSCHLUSS: Seien Sie mit ThrottleStop sehr vorsichtig, es gibt Ihnen die vollständige Kontrolle über Ihre CPU, was bedeutet, dass Sie Ihre (oder die Ihres Unternehmens) Hardware braten könnten, wenn Sie nicht wissen, was Sie tun.

CLI: 6.0.7
Betriebssystem: Windows 10
CPU: Intel I7-7820HQ
MEM: 32 GB

Für Leute mit verrückt langsamen Build-Zeiten mit build -prod überlasse ich Ihnen einige Ratschläge, die uns geholfen haben: Wir haben Bootstrap in die scss-Datei jeder Komponente aufgenommen, was dazu führte, dass Bootstrap ~ 160 Mal in unser Projekt aufgenommen wurde. Die Build-Ausgabe war nicht nur groß (50 MB oder so entpackt), sondern der Build nahm auch wahnsinnig viel Zeit in Anspruch, 30 Minuten. Jetzt sind wir bei ein paar Minuten und ~4 MB unkomprimiert.

Wenn Sie Zweifel haben, können Sie Ihr Hauptpaket in einem Texteditor öffnen und sich fragen, ob Sie viele überflüssige Dinge sehen. Gehen Sie von dort aus. Das war der Tipp für uns.

Das hat epische Ausmaße angenommen! Jemand sieht das langsam?.

Build-Zeiten wurden mit ng6 zu einem Albtraum. Das Problem scheint etwas mit der Quellkartengenerierung zu tun zu haben. Was ich für Prod-Builds deaktivieren kann, aber für Entwicklungszeit und Debug sind diese unerlässlich.

CLI: 6.0.8
Betriebssystem: macOS 10.13.4
CPU: 3,1 GHz Intel Core i7
MEM: 16 GB

In 90% der Fälle werden Quellkarten mit der folgenden Ausgabe generiert

92% after chunk asset optimization SourceMapDevToolPlugin main.js generate SourceMap

Es belastet die Entwicklerleistung dramatisch und wird zum Showstopper.

Ich würde mich sehr über ein Update vom Team hier freuen. Ist euch das bewusst? Gibt es Investitionen, um die Bauzeiten zu verkürzen?

das hat das Problem behoben ng build --prod --build-optimizer true --aot true

Nein nicht wirklich. Sehen immer noch Bauzeiten, die schrecklich sind.

Aus irgendeinem Grund tritt bei unseren E2E-Tests (Zypresse) ein Fehler nur auf CI auf.

Der angezeigte Fehler sagt nicht viel aus und ich kann den Stacktrace nicht abrufen.

Ich habe jedoch Sentry und alle Fehler werden dort gemeldet, was großartig ist! Aber... Da die Sourcemap nicht funktioniert, kann ich mich vorstellen, dass die Überprüfung eines hässlichen Quellcodes alles andere als ideal ist.

Sentry unterstützt Sourcemaps :raised_hands: Aber ich kann sie nicht bereitstellen, da sie nicht einmal lang sind, es stürzt nur ab, während mit Sourcemaps gebaut wird. Auf CI, aber auch auf meinem Computer, der 32 GB RAM und im Allgemeinen eine recht gute Konfiguration hat.

92% after chunk asset optimization SourceMapDevToolPlugin main.3b1b07dccf0137765ba6.js generate SourceMap

#
# Fatal error in , line 0
# API fatal error handler returned after process out of memory
#
#
#
#FailureMessage Object: 0x7f89267de9b0Illegal instruction (core dumped)

@maxime1992 Ich wette, es ist Ihr Node v8-Speicherlimit, wer es scheißt und nicht Ihr Maschinenspeicherlimit
Es ist ein bekanntes Problem mit v8 tatsächlich ... es kann eine echte Hündin sein, wenn es um große / lange Strings ohne Chunking geht (Knoten haben afaik eine feste Begrenzung der Stringlänge)

Meiner Meinung nach kann v8 eine echte Qual sein, mit DATEIEN umzugehen und sie zu analysieren ... wegen dieser Grenzen.
einige refs
https://futurestud.io/tutorials/node-js-increase-the-memory-limit-for-your-process
https://bugs.chromium.org/p/v8/issues/detail?id=847

Ich habe auch einen enormen Anstieg seit der Migration zu NG6 gesehen:-

beim Laufen

ng build --prod --output-path ~/Desktop/KaiSuite/public

Date: 2018-07-14T09:30:25.804Z
Hash: d580dd49dcd4e6917e1b
Time: 607608ms
chunk {0} runtime.a66f828dca56eeb90e02.js (runtime) 1.05 kB [entry] [rendered]
chunk {1} styles.6e13815b16b2c751820b.css (styles) 572 kB [initial] [rendered]
chunk {2} polyfills.7a0e6866a34e280f48e7.js (polyfills) 59.6 kB [initial] [rendered]
chunk {3} main.8dfd3d83f3bae347a6a4.js (main) 1.02 MB [initial] [rendered]



md5-00b0c2f6e24c195e5434b8e31f39bc03



WARNING in Invalid background value at 147:97. Ignoring.
WARNING in Invalid background value at 171:56164. Ignoring.



md5-befa16717a3fbbae6779a1fbea7fbbc6



Angular CLI: 6.0.8
Node: 8.10.0
OS: linux x64
Angular: 6.0.7



md5-24d7ce565fb239f31090503f2b33051c



      1 /browserslist
      1 gitkeep
     24 html
      1 ico
      4 jpg
      1 js
      3 json
      6 png
     24 scss
     59 ts



md5-5f8512bfe0107d834bcf67ded02ee631



Unknown option: '--sourcemaps'

und --build-optimizer=false Ergebnisse sind nicht anders.

:arrow_up: Ich glaube, es hat sich geändert in --source-maps @thenslerse

Die letzten Updates haben die Situation hier stark verbessert. Beachten Sie, dass der Build ziemlich viel RAM benötigt, ~2Go here.

Ich weiß nicht, was mit Ihrem Build nicht stimmt, aber als Referenz hier meine Konfiguration:

 $ ./node_modules/.bin/json -D'/' -f angle.json /projects/gestemps-front/architect/build/configurations/prod
 {
 "fileReplacements": [
 {
 "replace": "projects/gestemps-front/src/environments/environment.ts",
 "with": "projects/gestemps-front/src/environments/environment.prod.ts"
 }
 ],
 "Optimierung": wahr,
 "outputHashing": "alle",
 "sourceMap": falsch,
 "extractCss": wahr,
 "namedChunks": falsch,
 "aot": wahr,
 "extractLicenses": wahr,
 "vendorChunk": falsch,
 "buildOptimizer": wahr,
 "serviceWorker": wahr
 }

 $ find projects/gestemps-front/src/ -type f | sed -e 's/.*\.//' | sortieren | uniq -c
 4 eot
 1 gitkeep
 212 html
 1 ico
 1 jpg
 1 json
 48 png
 248 sss
 10 svg
 667 t
 26 ttf
 4 woff
 4 woff2
 $ ng build -c prod gestemps-front

 Datum: 2018-07-24T14:48:59.473Z
 Hash: ea9d61387d2af3ceabd9
 Zeit: 99707ms
 Block {22} 22.b59b168f3e26e58f571f.js () 7,26 kB [gerendert]
 Chunk {Skripte} scripts.abc521399cddc9dfff22.js (Skripte) 213 kB [gerendert]
 Block {0} common.f9ace648256335434c07.js (allgemein) 37,8 kB [gerendert]
 Block {1} 1.5499a61f5e0ceef51961.js () 32,1 kB [gerendert]
 Block {2} 2.eba1d4227d25e1530c33.js () 18,1 kB [gerendert]
 Stück {3} 3.e1f9d5b9a8f8e7380574.js () 23,7 kB [gerendert]
 Stück {4} 4.d42fe05fbd7e1f8813f7.js () 108 kB [gerendert]
 Block {5} 5.23850a79a8216953a8a7.js () 226 kB [gerendert]
 Block {6} 6.4177f7ded01dad458a17.js () 24,1 kB [gerendert]
 Block {7} 7.3a4dadc888d3ecf86a20.js () 43.8 kB [gerendert]
 Brocken {8} 8.b5f37ef38c0266a0bff2.js () 26,2 kB [gerendert]
 Brocken {9} 9.a9f9f788ab594d3ecfdf.js () 16,2 kB [gerendert]
 Block {10} 10.e486711476a941ac9dec.js () 96,9 kB [gerendert]
 Block {11} 11,8e127c54d67e9335e8c3.js () 30,9 kB [gerendert]
 Block {12} 12.9f4ed703f1168dccf5cf.js () 80,1 kB [gerendert]
 Block {13} 13.6db615c37ecc172c5fa6.js () 30,2 kB [gerendert]
 Block {14} 14.052b7686366bb2f26d24.js () 38,3 kB [gerendert]
 Block {15} 15.e2245a819668c46a01c4.js () 37,5 kB [gerendert]
 Block {16} 16.7c535aedcaff7253bd08.js () 106 kB [gerendert]
 Block {17} 17.06a436c11b3a72156b8d.js () 112 kB [gerendert]
 Block {18} 18.e6819dd4cc3210927d4a.js () 39,7 kB [gerendert]
 Brocken {19} 19.d696738f06a391d0cb80.js () 39,3 kB [gerendert]
 Block {20} 20.3e01f7381cc58596f370.js () 92,2 kB [gerendert]
 Block {21} 21.ee46112cf361a8bca156.js () 7,4 kB [gerendert]
 Brocken {23} 23.e23d4566a33d8f9c8885.js () 43,9 kB [gerendert]
 Block {24} 24.aec6824d1689bdd4eb64.js () 25,3 kB [gerendert]
 Block {25} 25.8be5ea48dca99238076e.js () 62,8 kB [gerendert]
 Block {26} 26.7a0050c51f531d1139fd.js () 46,1 kB [gerendert]
 Chunk {27} 27.f2741b48d64773848311.js () 79,1 kB [gerendert]
 Block {28} 28.f706a121c03421ba3186.js () 51,8 kB [gerendert]
 Block {29} 29.6dc6da300b9570ccca0a.js () 47,1 kB [gerendert]
 Block {30} 30.bc47c5ac2ec1d443d19a.js () 56,4 kB [gerendert]
 Block {31} 31.9d8ed35e97ae1001f6c5.js () 91,6 kB [gerendert]
 Block {32} 32.3b4c316116b309503cb6.js () 116 kB [gerendert]
 Block {33} 33.8cfe4f67375db93fa434.js () 37,6 kB [gerendert]
 Block {34} 34.6ce051529c0407f5b008.js () 129 kB [gerendert]
 Stück {35} 35.ba4d73fed5e6e11a29b4.js () 6.17 kB [gerendert]
 Block {36} 36.13018565227fa5fd45f9.js () 5,8 kB [gerendert]
 Block {37} 37.c14950ef72fdab47b533.js () 264 kB [gerendert]
 Brocken {38} 38.99504dfac9f13b5e20e9.js () 86,8 kB [gerendert]
 Stück {39} 39.0bf52b854d08e0037da5.js () 367 kB [gerendert]
 Chunk {40} runtime.116953fa95d6d856c696.js (Laufzeit) 2,85 kB [Eintrag] [gerendert]
 Chunk {41} style.10b82f02a98f259af35b.css (Stile) 258 kB [initial] [gerendert]
 Chunk {42} polyfills.6f9dd0fcb5982023a125.js (Polyfills) 101 kB [initial] [gerendert]
 Chunk {43} main.4d929acb0b2780c3ca2d.js (main) 2,13 MB [initial] [gerendert]

 Winkel-CLI: 6.0.8
 Knoten: 10.6.0
 Betriebssystem: Linux x64
 Winkel: 6.0.9

Hey Leute, ich hatte ein Problem mit nicht genügend Arbeitsspeicher und bin über eine Lösung für den langsamen Build gestolpert (zumindest für uns).
Es stellte sich heraus, dass das Bewerfen des Speichers das Problem behoben hat. Hier ist unser Build-Befehl:

node --max_old_space_size=5048 ./node_modules/@angular/cli/bin/ng build --prod --sourcemaps false

YMMV und es ist ein bisschen hackig, aber ich hoffe, es hilft jemandem da draußen.

Hier ist ein Datenpunkt für den Vorschlag von @Brandon-Born. Es verringerte die Prod-Build-Zeit meines Projekts von über 50 Minuten auf etwa 13 Minuten. 👍.

Angular CLI: 1.6.3
Node: 8.9.4
OS: darwin x64
Angular: 5.2.1

Ich hatte das gleiche Problem.

Das Problem lag in meiner app.scss- Datei und der Art und Weise, wie ich eine Bibliothek importiert habe:

<strong i="8">@import</strong> "../../node_modules/bootstrap/scss/bootstrap"
Time: 224909ms

vs:

<strong i="12">@import</strong> "~bootstrap/scss/bootstrap";
Time: 19256ms

Angular CLI: 6.1.3
Node: 9.7.0
OS: darwin x64
Angular: 6.1.3

Dieser Thread ist einfach riesig und ich habe ihn immer noch abonniert, nur um zu wissen, wo einige seltsame Schuldige sind, die ohne erkennbaren Grund die Dinge ins Unermessliche treiben. Entschuldigen Sie, dass ich versucht habe, Sie @jpsk einer der größten Schuldigen für die Existenz dieses Problems sein?

@ShadowManu Ich habe den Kommentar von @jpsk zu einem neuen Projekt ausprobiert und keinen erkennbaren Unterschied bei einem Prod-Build festgestellt (11544 ms vs. 11724 ms).

Etwas, von dem ich weiß, dass es einen großen Unterschied machen kann, ist die von uns verwendete Version von uglify, die von https://github.com/angular/angular-cli/pull/11996 verbessert werden sollte

Das Erhöhen des Speicherlimits wie bei @Brandon-Born ist kein Hack und etwas, mit dem Sie irgendwann rechnen sollten. Knotenprozesse haben ein Standardspeicherlimit von etwa 1,7 GB. Wenn ein Knotenprozess beginnt, sich dem Speicherlimit zu nähern, muss er immer mehr Zeit mit der Garbage Collection verbringen, um Speicher freizugeben, was wiederum dazu führt, dass er langsamer läuft.

Größere Projekte verbrauchen mehr Speicher als kleinere Projekte, sodass ein Projekt irgendwann an die Speichergrenze stößt. Ich persönlich verwende dafür ein npm Skript:

"ng-high-memory": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng",

Es ist schwierig, auf viele dieser Berichte zu reagieren, da es keine objektive Reproduktion gibt, der wir folgen können. Es ist nicht so, dass wir nicht glauben, dass Builds langsam sein können. Aber Builds können aus vielen Gründen langsam sein. Es ist sehr wahrscheinlich, dass die Projekte mit den dramatischsten Buildzeiten irgendwo in der Pipeline an einem seltsamen Problem leiden, das kein allgemeines Problem ist, und für diejenigen, die wir wirklich reproduzieren müssen, um es zu beheben.

Allgemeine Leistungsverbesserungen sind natürlich immer hilfreich und wir versuchen sie so gut wie möglich umzusetzen. Aber der absolut beste Weg, uns dazu zu bringen, Probleme zu beheben, insbesondere solche, die schwer zu beheben sind, besteht darin, konkrete Repros anzubieten.

Hier sind meine neuesten Zahlen mit 6.1.5.

node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build --prod --source-map

_Zeit: 3.117.385ms (52min)_

ng build --prod --source-map

_Zeit: 8.416.746ms (140min)_

Hoffentlich hilft der Wechsel von uglify hier wirklich.

Der Speicherwechsel/-rat hat unseren Prod-Build von 48 Minuten auf coole 10 Minuten gebracht. Einfach durch Hinzufügen der Variablen max_old_space_size. Gute Arbeit @Brandon-Born!
Seltsamerweise haben wir dies auf den Windows-PCs von DEV nicht gesehen.
Ich werde auch auf die knappere Änderung warten, aber dies war eine ziemlich nützliche Seite, die man sagen muss.

Mit diesen:

@angular-devkit/architect 0.8.1
@angular-devkit/build-angular 0.8.1
@angular-devkit/build-optimizer 0.8.1
@angular-devkit/build-webpack 0.8.1
@angular-devkit/core 0.8.1
@angular-devkit/schematics 0.8.1
@angular/cli 6.2.1
@ngtools/webpack 6.2.1
@schematics/angular 0.8.1
@schemas/update 0.8.1
rxjs 6.3.2
Typoskript 2.9.2
Webpack 4.18.0

Laufen node --max_old_space_size=12000 ./node_modules/@angular/cli/bin/ng build --prod --source-map

Ich bin jetzt unten bei Zeit: 470558 ms (8 min).

Viel besser und erträglich. Scheint, als ob max_old_space_size in tsconfig.app.json konfigurierbar sein sollte

Ich wollte das nur für den Fall meiner Firma hinzufügen, weil unser CI/CD-Server nur 2 GB RAM hatte. Mit nur 2 GB wurde der Build nie abgeschlossen. Als wir den CI/CD-Dienstleister baten, den Arbeitsspeicher auf 3 GB auf 4 GB aufzustocken, war unser Build in etwa 3 Minuten fertig.

Wenn Sie dieses Problem also auf Ihrem Build-Server, aber nicht auf Ihrem Laptop sehen, überprüfen Sie zuerst, wie viel RAM Sie auf dem Build-Server haben.

@jpsk Vielen Dank für Ihre Lösung in https://github.com/angular/angular-cli/issues/6795#issuecomment -416236486

Die Lösung bestand darin, in allen scss-Projektdateien ~ anstelle von ../../node_modules/ verwenden.

In meinem Fall hatte ich eine Build-Zeit von 2378409ms (~40 Minuten) und jetzt braucht es nur noch 96053ms (~1,5 Minuten).

Es ist sehr seltsam für mich - ich hatte den letzten Monat 11-Minuten-Builds.. aber vor 2 Tagen hatte ich ungefähr 40-Sekunden-Builds und jetzt wieder 11-Minuten-Builds. Ich habe nicht viele Dinge geändert - also keine Ahnung, wie ich zu seinen 40-Sekunden-Builds gekommen bin.

Alle OSX-Entwickler in unserem Team erlebten eine sehr hohe CPU-Auslastung und sehr langsame ng build und ng serve Zeiten (3-8 Minuten für den anfänglichen Build und/oder die Neukompilierung). Das Hochladen des Knotens auf Version 10.x über nvm , das Entfernen von node_modules aus dem Projekt und die Neuinstallation mit einem npm install verringerte die anfängliche Buildzeit auf etwa 30 Sekunden und die Neukompilierung auf etwa 12 Sekunden. Dies ist eine ziemlich große, eckige 6-Anwendung

Da ich alle Kommentare lese und meine eigene Winkel-6-Build-Zeit sehe, komme ich zu dem Schluss, dass UglifyJSPlugin mit 92% die meiste Zeit in Anspruch nimmt und auch RAM mehr als 2 GB RAM für nur einen Build verbraucht.

Alle OSX-Entwickler in unserem Team erlebten eine sehr hohe CPU-Auslastung und sehr langsame ng-Build- und ng-Serving-Zeiten (3-8 Minuten für den ersten Build und/oder die Neukompilierung). Das Hochladen von Node auf Version 10.x über nvm, das Entfernen von node_modules aus dem Projekt und die Neuinstallation mit einer npm-Installation verringerte die anfängliche Buildzeit auf etwa 30 Sekunden und die Neukompilierung auf etwa 12 Sekunden. Dies ist eine ziemlich große, eckige 6-Anwendung

Hat mir den Tag gerettet

gleicher Fehler :(

Datum: 2018-10-15T09:17:21.275Z
Hash: a8e9f7577a381cf027bd
Zeit: 338960ms
Block {0} 0.e38e03f2d9c6fd65370c.chunk.js (allgemein) 1,29 MB [gerendert]
Chunk {1} 1.35b3fdbd653e9c99e87e.chunk.js () 168 kB [gerendert]
Chunk {2} 2.78c04f64dba92e87b001.chunk.js () 12,7 kB [gerendert]
Chunk {3} 3.ef5382adf15030bf4d7f.chunk.js () 41,1 kB [gerendert]
Chunk {4} 4.ac5e7a11066bd3bce58a.chunk.js () 713 kB [gerendert]
Chunk {5} 5.261500741b47979be46e.chunk.js () 867 kB [gerendert]

Gleiches Problem unter OS X,
Letzte Woche waren es ungefähr 10 Minuten, aber dann ist etwas passiert und jetzt sind es ungefähr 50 Minuten..
Das nervt...
Werde ausprobieren, was

Unser Build mit diesen Parametern (ng build --prod --aot=false --optimization=true --sourceMap=false --buildOptimizer=false) erstellt 71 Bundles in etwas mehr als 2 Minuten mit einer Gesamtgröße von 11 MB für alle Bundles.

Jetzt setzen wir das Flag --aot auf true und was passiert?? Der Build dauert ca. 43 Minuten, kommt mit 84 Bundles und hat eine Gesamtgröße von 22 MB???? Soll AOT nicht die Größe minimieren, indem es ausschließt, was nicht verwendet wird? Aber stattdessen dauert es 41 Minuten, um doppelt so viel Code zu erstellen? Was ist hier los?

Wir hatten eine besonders schlimme Regression mit 7.0, die als https://github.com/angular/angular-cli/issues/12646 aufgeführt ist. Das Hauptproblem dort sollte mit @angular/core@~7.0.2 und [email protected] behoben werden.

@negberts nicht sicher, was in Ihrem Projekt wirklich passiert. Ist es Open Source oder könnte ich mir das irgendwo anschauen?

Soll AOT nicht die Größe minimieren, indem es ausschließt, was nicht verwendet wird?

Nein, bei aot geht es darum, Ihre Vorlagen vorzukompilieren und den Start von Apps/Modulen zu beschleunigen, indem der Laufzeitcompiler und die Laufzeitkompilierungsphase entfernt werden

@artaommahe das meinte ich wohl. ;-) Aber um ehrlich zu sein, habe ich die Erfahrung gemacht, dass die --aot=false Version tatsächlich schneller startet.. Nicht sehr seltsam finde ich, wenn man die Gesamtgröße der Bundles vergleicht…

@filipesilva leider nicht :-( Aber alle Pakete sind aktuell. Ich habe die Build-Ergebnisse angehängt. Brauchst du noch etwas? Angular.json? Package.json?

ngbuildcompare.xlsx

@negberts aot kompiliert die HTML-Vorlagen in einfache js-Dateien vor, die die Ansicht auf dem neuesten Stand halten. Diese sind größer als die Vorlagen selbst, daher gibt es einen Punkt, an dem die kombinierte Größe die Größe des Laufzeitcompilers übersteigt.
Es spart Zeit zur Laufzeit, da es ein Schritt im Voraus ist.

Aber Sie haben darauf hingewiesen, dass die Bundles so viel größer sind, dass Sie denken, dass das Nicht-Aot schneller startet. Dies kann für nicht zwischengespeicherte Assets zutreffen, plus den Unterschied beim Parsen einer größeren Datei. Ich baue in ein einzelnes Bundle ein, daher sollten Ihre Erfahrungen mit so vielen Bundles anders sein.

Ich schlage vor, dass Sie diese Optionen auch auf verschiedenen Geräten vergleichen. Mobil und Desktop, und behalten Sie die bessere Leistung.

Seit neueren Versionen kann ich appveyor CI nicht mehr verwenden, da der Build länger als eine Stunde läuft.
Ich habe auf die neueste Version aktualisiert (von 6 auf 7), in der Hoffnung, dass es sich verbessern würde, aber es wurde nur noch schlimmer.
Ich habe versucht, build-optimizer=false aber der Build schlägt fehl (Was??).
Ich würde mich über ein paar Einblicke freuen, ich bin verzweifelt...
Code finden Sie hier:
https://github.com/IsraelHikingMap/Site
Appveyour-Build finden Sie hier:
https://ci.appveyor.com/project/IsraelHikingHost/site
Der entsprechende Zweig, an dem ich gerade arbeite, heißt openlayers.
Bitte lassen Sie es mich wissen, wenn Sie noch etwas benötigen.
Der Produktions-Build lief in der Winkelversion 4-5 ungefähr 10 Minuten, denke ich ...
Ich habe Appveyor eine herzzerreißende E-Mail geschickt und sie gebeten, das Timeout zu verlängern. Ich hoffe, sie würden helfen, aber ich möchte wirklich, dass mein Build weniger Zeit in Anspruch nimmt, dies ist keine große App ...

@HarelM 2 Dinge, die Sie ausprobieren könnten, die mir zu helfen schienen. Aktualisieren Sie @angular-devkit/build-angular Sie haben Version 8, aber Version 10 ist draußen (nicht sicher, warum dies nicht aktualisiert wird, wenn Sie die cli oder etwas anderes aktualisieren)

Du mischst auch scss und css. Was nicht so aussieht, als wäre es eine große Sache, aber als ich alle meine CSS-Dateien in CSS konvertierte, sah ich, dass meine Build-Zeit ziemlich zurückging.

Ich habe es gerade in Ihrem Repo ausprobiert und keine großen Veränderungen festgestellt, aber der Build dauerte bei mir nur etwas mehr als eine Minute.

@hahn-kev Danke für die superschnelle Antwort!
Wie hier im openlayers-Zweig zu sehen ist, ist die Devkit-Version 0.11:
https://github.com/IsraelHikingMap/Site/blob/dd78814bc11b86fc66157943e79e3a3d8e85488d/IsraelHiking.Web/package.json#L60
Ich werde versuchen, alle meine CSS-Dateien zu scss zu migrieren, obwohl ich eine von icomoon generierte habe, die ich nicht jedes Mal migrieren möchte, wenn ich sie ändere, aber wenn es die Build-Zeit verkürzt, werde ich es versuchen.

Aber der Aufbau hat bei mir nur etwas mehr als eine Minute gedauert.

Hast du es mit --prod ?
Auf jeden Fall sind die Appveyor-Server ressourcenbegrenzt und es dauert dort sehr lange. Sie waren so freundlich, die Auszeit jetzt auf 90 Minuten zu verlängern, ich hoffe, es wird reichen...

@HarelM Ja, ich habe es mit --prod aber dies ist ein schöner Desktop, also definitiv schneller als das, was Sie von Appveyor erhalten.

Oh ok, ja, ich habe den Openlayers-Zweig nicht gebaut. Aber ich hatte wirklich langsame Build-Zeiten bei der Verwendung von Quellkarten, wenn ich Scss und CSS hatte. Aber es sieht nicht so aus, als ob Sie Quellzuordnungen aktiviert haben, also haben Sie vielleicht ein anderes Problem?

Ich sehe jetzt, dass die Debug-Builds bei Verwendung des Flags --watch in Angular 7 jetzt deutlich langsamer sind (ca. 10-15 Sekunden statt 2-3). Ich erwäge ein Downgrade auf 6... :-(

TL;DR: increase-memory-limit Paket verwenden.
Nach langem Ausprobieren kam ich zu diesem Problem: #5618, das bei meinen Builds auftrat.
Ich werde eine nette Lösung im obigen Problem posten, aber anscheinend reduziert es die Build-Zeit erheblich, wenn dem Knoten mehr Speicher zur Verfügung steht - der Build, der 43 Minuten dauerte, ist jetzt in etwa 5 Minuten abgeschlossen! :-)))
Hoffe das hilft auch anderen.

@thenslerse , Entschuldigung, dass ich Sie hier mit

WARNING in Invalid background value at 147:97. Ignoring.
WARNING in Invalid background value at 171:56164. Ignoring.

Angular Universal ist zu langsam aufzubauen, dauert mehr als 20-30 Minuten und ist nicht glatt aufzubauen und freizugeben. kann es nicht vereinfacht werden? Ich mache den Client-Build, dann einen Server-Build, dann wieder ein Webpack, um eine server.js zu packen, die zu allen Plugins passt, die wir hinzufügen, in der Nähe einer 24-30-MB-Einzeldatei. braucht definitiv einen vereinfachten Weg oder einen schnellen Build-Flow.

@Brandon-Born Danke!!!

Ich kann nicht einmal ein kleines Boilerplate-basiertes Projekt (Angular-Material, 2-3 Dutzend sehr kleine Module, <5k LoC insgesamt) auf einer 1-GB-RAM-EC2-Instance kompilieren, selbst wenn alle möglichen speicherintensiven Optionen deaktiviert sind:

"optimization": false,
"outputHashing": "all",
"sourceMap": false,
"extractCss": false,
"namedChunks": false,
"aot": false,
"extractLicenses": false,
"vendorChunk": false,
"buildOptimizer": false

Selbst wenn alle diese Flags deaktiviert sind, dauert dies auf meinem lokalen Computer ungefähr 1,2 GB RAM und ungefähr 30 Sekunden, um auf einem i7-basierten Computer aufzubauen. Inakzeptabel.

@skylarmb Von

Mit JS tauschen Sie Ressourcen für Flexibilität und Komfort aus.

Wenn Sie weniger RAM verwenden möchten, verwenden Sie GoLang. ;)

@alberto-chiesa (Trolling akzeptiert :-)) Obwohl es vom Angular-Team keine wirklichen Benchmarks für eine solche Verarbeitung gibt, können wir beim Kompilieren deutliche Rückschritte sehen. Ein Angular-7-Projekt mit einer ähnlichen Anzahl von Dateien wie ein Angular-5-Projekt dauert hier auf unseren Entwicklungsumgebungen 5x so lange. Es sollte auch beachtet werden, dass dies nach Speicher- und anderen Optimierungen ist, ohne diese dauerte es fast 8x so lange. Wir sind hier rückwärts gegangen.
Beide Jenkins-Boxen haben ähnliche Fähigkeiten und genügend Ressourcen für eine Standardkompilierung.
Angular 7 ist in seinen Kompilierungszeiten sehr langsam, dafür gibt es allein in diesem Beitrag genug Beweise.
Der inakzeptable Teil ist, dass Entwicklungsteams aufgehalten werden, die Boxen überladen sind und es im Allgemeinen ineffizient aussieht.
Ein paar Dateien sollten, wie das Poster vorschlägt, nicht länger dauern als der Sass-Build, der für uns etwa 5 Sekunden dauert. Rückblickend auf die Jahre der Zusammenstellung glaube ich nicht, dass wir mit unseren Forderungen hier unvernünftig sind.

@inthegarage Ich sage nicht, dass es keine Probleme gibt. Ich verfolge diesen Thread von Anfang an. Ich sage nur, dass es naiv ist, zu bedenken, dass der Angular-Build mehr als 1 GB RAM benötigt. Das Problem ist die Zeit: Wenn der Build 5x langsamer ist, ist es ein Problem (ein großes). Aber wenn ich die gleiche Build-Zeit mit mehr RAM erreichen kann, wird es weniger problematisch.
Auch hier möchte ich niemanden trollen, und ich bin mir der langen Build-Zeiten bewusst, aber das Build-Hardware-Ziel kann nicht "eine 1-GB-RAM-EC2-Instance" sein. Wenn du sagst: "Build time is too slow", bin ich zu 100% bei dir.
Wenn Sie sagen "Build braucht zu viel RAM", kann ich nur sagen "es wäre schöner, wenn es weniger brauchte, aber das ist mir wirklich egal".
Ich hoffe, ich habe diesen Punkt geklärt. Kein Trolling beabsichtigt :)

@alberto-chiesa Einverstanden, es gibt einige naive Annahmen und wenn eine IDE 3 GB+ spielerisch beanspruchen kann, ist es nicht realistisch, von einem Compiler zu erwarten, dass er weniger verwendet. Alle Punkte geklärt.
Ich wünschte auch, es gäbe mehr Dringlichkeit und Aktivität bei diesem Problem. Wir scheinen uns in einer "Jam morgen"-Situation zu befinden. Erstens war warten auf Terser, zweitens war es Winkel 7 versuchen, dann mit einigen Einstellungen herumspielen. Nichts hat die Bauzeiten richtig verkürzt und das ist sehr frustrierend.

Hallo zusammen,

Nach dem Upgrade aller Abhängigkeiten werden unsere Kompilierungszeiten deutlich erhöht, von ~2min auf über 25min (wir haben nicht so lange gewartet).

Bei der Überprüfung, welche Abhängigkeiten das Problem haben, haben wir die letzte Version von Terser gefunden. Wir lösen das Problem, indem wir es auf 3.8.1.

Hey alle zusammen,

Kürzlich gab es zwei Leistungsrückgänge, die 7.x betrafen.

Die erste war in CLI 7.0 von https://github.com/angular/angular-cli/issues/12646 betroffen, behoben von https://github.com/angular/angular/pull/26734 und https://github .com/Microsoft/TypeScript/pull/28028.

Verwenden Sie mindestens [email protected] , @angular/[email protected] und `@angular-devkit/ build -angular@ https://github.com/angular/angular-cli/issues/12646# Issuecomment -435189691 sollte sich darum kümmern.

CLI 7.1 war betroffen von https://github.com/angular/angular-cli/issues/13102 , das von https://github.com/angular/angular-cli/pull/13309 behoben wird und nicht mehr @angular-devkit/[email protected] ).

Ich denke, dass es in der Vergangenheit nützlich war, dieses einzelne Problem für alle leistungsbezogenen Probleme zu haben, aber es ist nicht mehr so ​​​​nützlich. Zwischen damals und heute ist mehr als ein Jahr mit vielen neuen Versionen von Angular CLI vergangen.

Während dieser Zeit traten eine Reihe von Leistungsrückgängen auf, wurden behoben und neue kamen hinzu. Das gesamte Feedback in einem einzigen Thread zu haben, macht es schwierig, aussagekräftige Berichte zu erhalten oder die Leute darüber zu informieren, welche Versionen die sie betreffenden Regressionen behoben wurden.

Zum Zeitpunkt des Schreibens dieses Kommentars gibt es 116 versteckte Kommentare:

Bei so vielen versteckten Kommentaren ist es für die Leute schwierig, Informationen in anderen als den neuesten Kommentaren zu finden. Aber andererseits glaube ich nicht, dass die meisten Leute sowieso alle Kommentare durchgehen würden. Neue Benutzer, die diesen Thread sehen, lesen meistens die ersten und neuesten Kommentare und verlieren zwischendurch Gesagtes.

Anstatt dieses Mega-Problem zu haben, werden wir versuchen, aktuelle Leistungsprobleme mit großen Auswirkungen oben im Issue-Tracker zu fixieren:

Im Allgemeinen, wenn Sie die neueste Version des CLI-Build-Systems verwenden (das ist @angular-devkit/build-angular und sollte auf Ihrem package.json ) und ein Leistungsproblem bemerken, überprüfen Sie bitte die angehefteten Probleme. Wenn Sie dort keine leistungsbezogenen Informationen sehen, öffnen Sie bitte eine neue.

Eine andere Sache, die Sie beachten sollten, ist die Speichernutzung, die ein ähnliches Problem in https://github.com/angular/angular-cli/issues/5618 hat. Größere Projekte benötigen mehr Speicher zum Erstellen, und wenn Sie sich nahe an der Speichergrenze befinden, kann die Leistung darunter leiden. Bitte beachten Sie, dass die Projektgröße nicht nur Ihr Quellcode ist, sondern auch alle von Ihnen verwendeten Bibliotheken umfasst.

Bitte überprüfen Sie meinen Kommentar in https://github.com/angular/angular-cli/issues/5618#issuecomment -450151214, um zu sehen, wie Sie das Speicherlimit erhöhen können.

Aus den oben genannten Gründen (hohe Menge an Kommentaren, versteckte Kommentare, schwer zu melden und zu informieren) schließe ich auch dieses Problem, um zu verhindern, dass dieser Kommentar verloren geht, wenn neue Kommentare eingehen.

Vielen Dank an alle, die diese Leistungsprobleme gemeldet und bei der Diagnose geholfen haben. Wenn Sie auf neue stoßen, öffnen Sie bitte eine neue Ausgabe, damit wir dieser spezifischen Regression unsere volle Aufmerksamkeit widmen und eine Lösung dafür finden können.