angular-cli: Build with "ng -prod" is extremely slow

on my case it takes a whooping 42 mins to finish

Same issue here. Im using @angular/cli: 1.4.2 node: 8.5.0 Os: Mac os sierra. Script: ng build --prod --env=prod

For me it used to be ~30mins now its ~1h 20mins

@filipesilva how is Angular-cli tested with real life projects? 20-50 modules and 5-10 thirdpary JS Libs?

@angular/cli@1.7.0-beta.2 includes a bunch of production perf optimizations:

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

We hope these will improve production build times overall.

I had same issue.

The problem was in my app.scss file and the way I imported a library:

@import "../../node_modules/bootstrap/scss/bootstrap"
Time: 224909ms

vs:

@import "~bootstrap/scss/bootstrap";
Time: 19256ms

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

1.7.3 still very slow.

Hey folks, I had an out of memory build issue and stumbled across a fix for the slow build (for us at least). It turns out, throwing memory at it fixed the problem. Here’s our build command:

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

YMMV and it’s a bit hacky but I hope it helps someone out there.

Anything on this @filipesilva? We are running ng build --prod --aot and having times of:

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

Build times became a nightmare with ng6. The problem seems to be something related to source-maps generation. Which I can disable for prod builds, but for development time and debug, those are essential.

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

90% of the time it’s generating source-maps with the following output

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

It’s draining the developer performance dramatically and starts to become a show stopper.

I’d really love to get some update from the team here. Are you guys aware of this? Is there some investment to speed up the build times?

@filipesilva Angular 5.1.0 and CLI 1.6 as well (I’m trying to build on MacOS Sierra). The most time waiting, I’m stuck at “92% chunk asset optimization”.

Happy to hear that 1.7.0 is helping keep prod build time manageable! We put in a lot of prod optimizations in 1.7.0.

I’ll leave this issue open for a few more weeks to see if there’s anything off with our fixes.

Using @angular/cli@1.7.0-beta.2 and angular@5.2.2 our build time looks normal again (aot+build optimizer enabled).

Before beta.2 (~50mins)

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]

After beta.2 (~8mins)

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]

Great job! Thanks @filipesilva

Very very slow here also, went from 7min to 42+ minutes. Using @angular/cli@1.7.0-beta.1 and also --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

@ShadowManu I had a try at @jpsk’s comment on a new project and saw no discernable difference on a prod build (11544ms vs 11724ms).

Something I know can have a big difference is the version of uglify we use, which should be improved by https://github.com/angular/angular-cli/pull/11996.

Increasing the memory limit like @Brandon-Born does is not a hack, and something you should expect to do at some point. Node processes have a default memory limit of about 1.7gigs. When a node process starts getting close to the memory limit it needs to spend more and more time doing garbage collection to free up memory, which in turn makes it run more slowly.

Bigger projects will use up more memory than smaller projects so at some point a project will hit the memory limit. I personally use a npm script for this:

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

It’s hard to act on many of these reports since there is no objective reproduction that we can follow. It’s not that we don’t believe that builds can be slow. But builds can be slow for many reasons. It’s exceedingly likely that the projects that are seeing the most dramatic build times are suffering from some odd problem somewhere in the pipeline that is not a general problem, and for those we really need to reproduce it to fix it.

General performance improvements are of course always helpful, and we try to do them as much as possible. But the absolute best way of getting us to fix issues, especially hard to fix ones, is to offer concrete repros.

😄

For people with crazy slow build times with build -prod I’ll leave you with some advice that helped us: We were including bootstrap into every component’s scss file which was causing bootstrap to be included ~160 times in our project. Not only was the build output large (50mb or so unzipped) but the build took crazy amounts of time, 30 min. Now we are down to couple minutes and ~4MB uncompressed.

If you have doubts you can open your main bundle in a text editor and start asking yourself if you are seeing a lot of redundant stuff. Go from there. That’s what tipped us off.

The issue is the vendor chunk is now being included the main chunk as far as I can tell [1] and uglify is churning away… Our build regressed from about 3m to >30m… I killed it before it even finished.

Passing --vendor-chunk=true resolves the issue without disabling the optimizer completely.

[1] https://github.com/angular/angular-cli/wiki/build search for build-optimizer

Same issue here:

Time: 565883ms

@angular/cli@1.6.0 and Angular 5.1.0

This may help someone.

All 4 of my CPU cores were running at 100% when I ran ng build --prod, which caused my laptop to throttle down from 3.7 ghz to 0.7 ghz due to high CPU temperatures, which was causing very long build times.

I ended up installing ThrottleStop and lowered my “Turbo Ratio Limits” when 3+ cores were in high use (to lower temps). Also adjusted my laptop fan profiles to increase fan speed when I had very high cpu usage.

DISCLAIMER: Be very careful with ThrottleStop, it gives you complete control of your CPU, which means you could fry your (or your companies) hardware if you don’t know what your doing.

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

Any update on this? We’re even to the point where we’re seeing JavaScript heap errors when we compile with sourcemaps turned on.

@skylarmb Unacceptable by who? Depending upon which absolute standard? The build of Javascript applications is complex. 1GB RAM is absolutely nothing. You should expect to have build occupy a lot of resources. The issue is time, not RAM usage. 30 seconds to build, considering you are starting at least 4 processors (tsc, sass, the whole npm thing, Uglify, WebPack, and who knows what else), is perfectly acceptable if there is a way to keep the development build shorter (which usually is the case).

With JS, you are exchanging resources for flexibility and convenience.

If you want to use less RAM, use GoLang. 😉

@jpsk Thank you for your solution in https://github.com/angular/angular-cli/issues/6795#issuecomment-416236486

The fix was to use ~ instead of ../../node_modules/ in all of the scss project files.

In my case I had a build time from 2378409ms (~40 mins) and now it needs only 96053ms (~1,5 mins).

Well, after spending most of two days making a copy of my project, then stripping modules/components out one at a time to track down the culprit, I got down to 2 feature modules and 1 common module and discovered that doing an ng build --prod -sm has an issue that causes it to hang (at 95% emitting) if any [styleUrls] contain CSS (empty css files are ok).

Looks like this is issue #8314

I put everything back to how I have my production project, modified all my components to not use [styleUrls], then ran ng build --prod -sm and after 4990841ms (83 min), it finally finished.

My /src/app stats are:

145 .ts (approx 10,200 non-blank lines) 55 .html (9.675 non-blank lines) 6 .css

If I also use --build-optimizer false, the time falls to 470616ms (7.8 min)

I’m having the issue.

Using ng build --prod it finishes in 74112ms. Using ng build --prod --sourcemaps true it hangs at 92% chuck asset optimization forever (left it running overnight). Using ng build --prod --sourcemaps true --build-optimizer false, it stops at 92% chunk asset optimization for a few minutes, then hangs at 95% emitting.

CPU at about 80% during chunk asset optimization, then drops to 30% during emitting.

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

ng --version Angular CLI: 1.7.2
Node: 8.9.4
OS: win32 x64
Angular: 5.2.7
… animations, common, compiler, compiler-cli, core, forms … http, language-service, platform-browser
… platform-browser-dynamic, router
@ angular/cli: 1.7.2
@ 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

+1 one word:slow,two words: too slow 400000++ ms how to fix this ,

but i can feel project 's size more slim now

@SV-efi Thanks, turning that off made a huge difference

After upgrading to 6.0, ng build --prod --source-map is still taking 40 minutes. ng build --prod --source-map --build-optimizer false takes 8 minutes.

Just installed 1.7.0-beta.3 and my build times are so much better! These improvements were super valuable to me! Thanks so much!

I encountered this issue. I needed to use --build-optimizer=false option to have a build time acceptable.

It’s very strange for me - i have had 11 minute builds for the last month… but 2 days ago i had some 40 second builds, and now back to 11 minute builds. I didn’t change many things - so no idea how i got he 40 second builds…

Here’s my latest numbers using the 6.1.5.

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

Time: 3,117,385ms (52min)

ng build --prod --source-map

Time: 8,416,746ms (140min)

Hopefully the switch from uglify will really help this.

This thread is just huge and I’m still subscribed to it just to know where are some weird culprits that blow things out of proportion without a discernible reason. Sorry for trying to invoke you @filipesilva but maybe the last comment from @jpsk can be one of the biggest culprits for the existence of this issue?

I have also seen a huge increase since migrating to NG6:-

when running

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]

That’s 10min to compile less than 60 typescript files.

I also get the following warnings when building a projects now:-

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

System info:-

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

cd src/ && find -type f | sed -e ‘s/.*.//’ | sort | uniq -c

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

I tested using --sourcemaps but get the following error:-

Unknown option: '--sourcemaps'

and --build-optimizer=false results are no different.

@dharmendrap7 Glad to hear it. I’ve since started using ng build --prod -sm --build-optimizer false --aot false

It’s even much faster to build and oddly it results in smaller bundle/chunk files. Might be a tad slower to bootstrap though - but not noticeably.

Just found that Firefox is really slow bootstrapping non-AOT compiled code.

Did anyone tried with latest RC? Any performance increase?

I removed all styleUrls from my components as a test, and build prod finally ran, but it took about 3 minutes to finish. I added the styleUrls back, and now build prod runs fine again! and in about 10 seconds.

This is really strange

Just did an upgrade to 1.7.3, and definitely seeing sourcemaps dragging down the build speed. Without sourcemaps, running a prod-build optimizer build takes about 74823ms. Enabling source maps on the exact same build kicks it up to 363124ms, about 5 times longer. Reasonably small project (about 129 source files, using Angular Material, rxjs, flex-layout, date-fns as the main library dependencies).

Wish there was a way to speed up sourcemaps without quintupling the build time.

Glad to hear it’s sorted 👍

@Toub @remisture @PascalTemel reasons for theses improvments are because build currently ignore fonts this decrease build time dramatically, when this enabled again it will still be slow and block at 92% … (joke)

I don’t know how you guys have theses improvments, seems not applied to me, ps: TBH i don’t care a little bit about build time, important to me is serve with aot in big project (>1k files), that is also improved to you ? first build ng s --aot : 90959ms rebuild ng s --aot : 27115ms rerebuild ng s --aot : 23896ms rererebuild ng s --aot : 0% blocking crashed

That’s definitely a long time. Does it get smaller if you pass --build-optimizer=false?

Isn’t AOT supposed to minimize the size by excluding what is not being used

nope, aot is about pre-compiling your templates and boosting up app/modules startup by removing runtime compiler and runtime compilation phase

Our build with these parameters (ng build --prod --aot=false --optimization=true --sourceMap=false --buildOptimizer=false) creates 71 bundles in just over 2 minutes with a total size of 11MB for all bundles.

Now we turn the --aot flag to true and what happens?? The build takes about 43 minutes, comes up with 84 bundles and has a total size of 22MB??? Isn’t AOT supposed to minimize the size by excluding what is not being used? But instead it takes 41 minutes to create twice as many code? What’s going on here?

All of the OSX developers on our team were experiencing very high CPU usage, and very slow ng build and ng serve times (3-8 minutes for initial build and/or recompile). Bumping node to version 10.x via nvm, removing node_modules from the project, and reinstalling with an npm install dropped initial build time to about 30 seconds and recompile to about 12 seconds. This is on rather large, angular 6 application

Saved my day @kellycrowther . Thanks, m8. I confirm that on os x with nodejs v10.11.0 I can see a significant improvement

Just wanted to add that for my company’s case, it was because our CI/CD server only had 2GB of RAM. With only 2GB, the build never finished. When we asked the CI/CD service provider to bump the RAM up to 3GB to 4GB, our build finished in roughly 3 minutes.

So if you are seeing this issue on your build server, but not on your laptop, first check how much RAM you have on the build server.

Here’s a data point for @Brandon-Born’s suggestion. It decreased my project’s prod build time from 50+ minutes to around 13 mins. 👍

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

Recent updates greatly improved the situation here. Note that the build takes quite some RAM, ~2Go here.

I don’t know whats wrong with your build, but for reference here is my config:

$ ./node_modules/.bin/json -D'/' -f angular.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"
    }
  ],
  "optimization": true,
  "outputHashing": "all",
  "sourceMap": false,
  "extractCss": true,
  "namedChunks": false,
  "aot": true,
  "extractLicenses": true,
  "vendorChunk": false,
  "buildOptimizer": true,
  "serviceWorker": true
}

$ find projects/gestemps-front/src/ -type f | sed -e 's/.*\.//' | sort | uniq -c
      4 eot
      1 gitkeep
    212 html
      1 ico
      1 jpg
      1 json
     48 png
    248 scss
     10 svg
    667 ts
     26 ttf
      4 woff
      4 woff2
$ ng build -c prod gestemps-front
Date: 2018-07-24T14:48:59.473Z
Hash: ea9d61387d2af3ceabd9
Time: 99707ms
chunk {22} 22.b59b168f3e26e58f571f.js () 7.26 kB  [rendered]
chunk {scripts} scripts.abc521399cddc9dfff22.js (scripts) 213 kB  [rendered]
chunk {0} common.f9ace648256335434c07.js (common) 37.8 kB  [rendered]
chunk {1} 1.5499a61f5e0ceef51961.js () 32.1 kB  [rendered]
chunk {2} 2.eba1d4227d25e1530c33.js () 18.1 kB  [rendered]
chunk {3} 3.e1f9d5b9a8f8e7380574.js () 23.7 kB  [rendered]
chunk {4} 4.d42fe05fbd7e1f8813f7.js () 108 kB  [rendered]
chunk {5} 5.23850a79a8216953a8a7.js () 226 kB  [rendered]
chunk {6} 6.4177f7ded01dad458a17.js () 24.1 kB  [rendered]
chunk {7} 7.3a4dadc888d3ecf86a20.js () 43.8 kB  [rendered]
chunk {8} 8.b5f37ef38c0266a0bff2.js () 26.2 kB  [rendered]
chunk {9} 9.a9f9f788ab594d3ecfdf.js () 16.2 kB  [rendered]
chunk {10} 10.e486711476a941ac9dec.js () 96.9 kB  [rendered]
chunk {11} 11.8e127c54d67e9335e8c3.js () 30.9 kB  [rendered]
chunk {12} 12.9f4ed703f1168dccf5cf.js () 80.1 kB  [rendered]
chunk {13} 13.6db615c37ecc172c5fa6.js () 30.2 kB  [rendered]
chunk {14} 14.052b7686366bb2f26d24.js () 38.3 kB  [rendered]
chunk {15} 15.e2245a819668c46a01c4.js () 37.5 kB  [rendered]
chunk {16} 16.7c535aedcaff7253bd08.js () 106 kB  [rendered]
chunk {17} 17.06a436c11b3a72156b8d.js () 112 kB  [rendered]
chunk {18} 18.e6819dd4cc3210927d4a.js () 39.7 kB  [rendered]
chunk {19} 19.d696738f06a391d0cb80.js () 39.3 kB  [rendered]
chunk {20} 20.3e01f7381cc58596f370.js () 92.2 kB  [rendered]
chunk {21} 21.ee46112cf361a8bca156.js () 7.4 kB  [rendered]
chunk {23} 23.e23d4566a33d8f9c8885.js () 43.9 kB  [rendered]
chunk {24} 24.aec6824d1689bdd4eb64.js () 25.3 kB  [rendered]
chunk {25} 25.8be5ea48dca99238076e.js () 62.8 kB  [rendered]
chunk {26} 26.7a0050c51f531d1139fd.js () 46.1 kB  [rendered]
chunk {27} 27.f2741b48d64773848311.js () 79.1 kB  [rendered]
chunk {28} 28.f706a121c03421ba3186.js () 51.8 kB  [rendered]
chunk {29} 29.6dc6da300b9570ccca0a.js () 47.1 kB  [rendered]
chunk {30} 30.bc47c5ac2ec1d443d19a.js () 56.4 kB  [rendered]
chunk {31} 31.9d8ed35e97ae1001f6c5.js () 91.6 kB  [rendered]
chunk {32} 32.3b4c316116b309503cb6.js () 116 kB  [rendered]
chunk {33} 33.8cfe4f67375db93fa434.js () 37.6 kB  [rendered]
chunk {34} 34.6ce051529c0407f5b008.js () 129 kB  [rendered]
chunk {35} 35.ba4d73fed5e6e11a29b4.js () 6.17 kB  [rendered]
chunk {36} 36.13018565227fa5fd45f9.js () 5.8 kB  [rendered]
chunk {37} 37.c14950ef72fdab47b533.js () 264 kB  [rendered]
chunk {38} 38.99504dfac9f13b5e20e9.js () 86.8 kB  [rendered]
chunk {39} 39.0bf52b854d08e0037da5.js () 367 kB  [rendered]
chunk {40} runtime.116953fa95d6d856c696.js (runtime) 2.85 kB [entry] [rendered]
chunk {41} styles.10b82f02a98f259af35b.css (styles) 258 kB [initial] [rendered]
chunk {42} polyfills.6f9dd0fcb5982023a125.js (polyfills) 101 kB [initial] [rendered]
chunk {43} main.4d929acb0b2780c3ca2d.js (main) 2.13 MB [initial] [rendered]

Angular CLI: 6.0.8
Node: 10.6.0
OS: linux x64
Angular: 6.0.9

@maxime1992 i bet its your its node v8 memory limit who sh*ts it and not your machine memory limit its a known problem with v8 actualy… its can be a real bitch when dealing large/long strings without chunking (node has a fixed string length limit afaik)

in my own opinion v8 can be a real pain handling FILES and parsing them … cause of those limits. some refs https://futurestud.io/tutorials/node-js-increase-the-memory-limit-for-your-process https://bugs.chromium.org/p/v8/issues/detail?id=847

I cant believe this is single threaded…

I ran into this with production builds (with source maps) hanging at 95% after upgrading to angular-cli 1.7.4 on Windows. Setting --sourcemaps=false, resolved the build issue for me.

I think that a lot of performance problems will be solved once we can upgrade Webpack to 4.

I saw some quite impressive benchmarks (execution times reduced by 60% to 90%). Unfortunately, this requires some work on many plugins. Nothing major, but there is a lot of small moving parts to be checked and minor fixes for Webpack breaking changes.

@todthomson could you take a CPU profile perhaps? I have some instructions in https://github.com/angular/angular-cli/issues/8259 that you could use.

@todthomson is this app something we could look at? Small apps exhibiting this sort of behaviour point towards some hard to find performance bugs.

I can confirm that now we build with optimizations in almost the same time as before (1.6.x), but with --build-optimizer=false.

Please, keep an eye on this subject, because build times are now acceptable, but “fast” is quite another thing.

Anyway, your work is so invaluable that no “thanks” is enough! And really, really appreciated. IMO, we just need to be more stable, predictable, fast (at both build and runtime) and slim. New features can come later.

Our large project is now ~2.35x Faster at building for aot/prod - THANK YOU

Here’s our measurements for Angular-CLI 1.6.4 (11.4min / 53MB) vs 1.7.1 (4.8min / 53MB):

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

@remisture This has already been fixed but you’ll need to wait for a new release

Awesome, 1.6.6=>1.7.0-rc.0 reduces my production build time from 18mn to 3mn!

Edit: here is the command I use to build:

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

Can confirm migrating angular-cli from 1.6.6 to 1.7.0-rc.0 resulted in a prod build reduction from 25 minutes to 3 minutes.

Here is analysis of our app. The build is of course single threaded so my macbook’s dual core processor is only half utilized. The system was mostly idle otherwise. I am running a second datapoint because this morning my first attempt at the 1.6 build was taking much longer than 18 minutes under similar conditions. But long story short, a much longer build for a 2% reduction in code size.

====

After (cli 1.6 with default optimizations and AOT):

Date: 2018-01-19T15:38:57.874Z Hash: f0ff32f352d583d9a60e Time: 1064637ms (18 mins) chunk {scripts} scripts.a09df21daa6632eb9407.bundle.js (scripts) 33.3 kB [initial] [rendered] chunk {0} 0.d021fc4a7108538dfdf5.chunk.js () 89.3 kB [rendered] chunk {1} main.b3bf84b1941b7f2c01c2.bundle.js (main) 4.42 MB [initial] [rendered] chunk {2} polyfills.50f916ca991d321c737c.bundle.js (polyfills) 624 kB [initial] [rendered] chunk {3} styles.ed292a274fc61d960e6a.bundle.css (styles) 422 kB [initial] [rendered] chunk {4} inline.c14b5104142c89623613.bundle.js (inline) 1.47 kB [entry] [rendered]

vendor + main = 4.42MB

Before (cli 1.4 with default optimizations and AOT)

Date: 2018-01-19T15:02:38.152Z Hash: 1be9e9d293dabdb3ca0d Time: 285541ms (5 mins) chunk {scripts} scripts.a09df21daa6632eb9407.bundle.js (scripts) 33.3 kB [initial] [rendered] chunk {0} 0.d021fc4a7108538dfdf5.chunk.js () 89.3 kB [rendered] chunk {1} polyfills.5b6fa84cc1992d5fb122.bundle.js (polyfills) 624 kB [initial] [rendered] chunk {2} main.9f0ad465d9688fbae36f.bundle.js (main) 1.59 MB [initial] [rendered] chunk {3} styles.ed292a274fc61d960e6a.bundle.css (styles) 422 kB [initial] [rendered] chunk {4} vendor.0d5ee7b13af3505dfd6a.bundle.js (vendor) 2.94 MB [initial] [rendered] chunk {5} inline.7abf96772a9fd0fe6c28.bundle.js (inline) 1.47 kB [entry] [rendered]

vendor + main = 4.53MB

Difference in time is +13 minutes Difference in size is -110KB

Thanks @filipesilva is there any analysis of the build speed or is build speed basically ignored because it’s considered a one-time payment for a long-time benefit?

How big are your projects btw? If you are on Linux/OSX/Git bash you can use this command to see your number of files by extension cd src/ && find -type f | sed -e 's/.*\.//' | sort | uniq -c.

We have a test project with a lot of TS files (https://github.com/filipesilva/angular-cli-test-repo) and it creates prod builds in 39m.

These are the files it has by extension:

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

The times you all are reporting are more than that… Do any of you have a project that I can take a look at and profile?

I have the same issue. Angular 5.1.0 and CLI 1.6 On Angular 4.4, it used to be around 40 seconds. Right now, it took more than 110 seconds. Usually, it’s around 300+ seconds.

FYI, it speeds up considerably when I leave off the --sourcemaps option. Off course, that’s a must have so it still needs a fix…

 [exec] Time: 111347ms