Build with "ng -prod" is extremely slow

Bug Report or Feature Request (mark with an `x`)

- [ x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

ng --version
_ _ ____ _ ___
/ \ _ __ __ _ _ | | __ _ _ __ / | | | |
/ △ \ | ' \ / _ | | | | |/ _ | '| | | | | | |
/ ___ | | | | (| | || | | (| | | | || | | |
// __| ||_, |_,||_,|| _|||
|___/
@angular/cli: 1.1.0
node: 7.9.0
os: win32 x64 (Win 10 Enterpirise - 16Gig , i7)
@angular/animations: 4.0.0
@angular/common: 4.0.0
@angular/compiler: 4.0.0
@angular/core: 4.0.0
@angular/forms: 4.0.0
@angular/http: 4.0.0
@angular/platform-browser: 4.0.0
@angular/platform-browser-dynamic: 4.0.0
@angular/router: 4.0.0
@angular/cli: 1.1.0
@angular/compiler-cli: 4.0.0
@angular/language-service: 4.0.0

Repro steps.

$ ng build --prod --aot=false -ec --sourcemap=false
Hash: 552d9867ececa788ac3a
Time: 670222ms
chunk {0} polyfills.d77767cee98c83f90386.bundle.js (polyfills) 294 kB {5} [initial] [rendered]
chunk {1} main.255e1d27fe4d40b56ab2.bundle.js (main) 1.51 MB {4} [initial] [rendered]
chunk {2} scripts.45a4574f31d7b91e5a5e.bundle.js (scripts) 3.88 MB {5} [initial] [rendered]
chunk {3} styles.ac17d766c993c4027892.bundle.css (styles) 228 bytes {5} [initial] [rendered]
chunk {4} vendor.86c029ec4598fb674488.bundle.js (vendor) 8.23 MB [initial] [rendered]
chunk {5} inline.750f0337ff0a9bee9813.bundle.js (inline) 0 bytes [entry] [rendered]

ng build --aot -ec -sm
Hash: 24f744145f250126e699
Time: 62809ms
chunk {0} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 294 kB {5} [initial] [rendered]
chunk {1} main.bundle.js, main.bundle.js.map (main) 3.07 MB {4} [initial] [rendered]
chunk {2} scripts.bundle.js, scripts.bundle.js.map (scripts) 3.88 MB {5} [initial] [rendered]
chunk {3} styles.bundle.css, styles.bundle.css.map (styles) 228 bytes {5} [initial] [rendered]
chunk {4} vendor.bundle.js, vendor.bundle.js.map (vendor) 7.37 MB [initial] [rendered]
chunk {5} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]

670222ms vs 62809ms is a huge difference

The log given by the failure.

There is no failure , the build takes a very long time to complete its stuck at
92% chunk asset optimization and then we have to wait for 10-15 mins to get the build completed.
I have disabled aot and sourcemaps, still the speed is very slow.

Desired functionality.

build should have similar time that to of ng build -aot

Any help and guidance to reduce will be helpful.

@filipesilva

@filipesilva Is this the expected behavior, do i need to change something ?

Production builds are usually slower than development builds. Besides using --aot, other optimizations are also used.

I do think your build time is too long though. I haven't seen other apps that have such a big difference between prod and dev build time. chunk asset optimization is a phase where sourcemaps are usually handled... but you have them turned off.

I'm unsure of what's happening. Perhaps it's related to webpack/webpack#4863.

Is this a public project that I can look at? You might also have a cyclic dependency perhaps.. if so, #6813 could help you.

Note: sourcemaps are disabled in production builds by default, while css extraction is enabled by default.

@filipesilva

Same problem here

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

@filipesilva you can check here if you can see import problem : https://plnkr.co/edit/xMf8HXoNIhq3urJ6cPXQ?p=preview

This is one proble "slow" but Other problem is : I don't understand why on dev mode "ng serve" after cli recompile fils changes and finish the browser autorefresh and I need wait 6-7seconds until browser finish refreshing this is very very big and make me crazy

@filipesilva

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

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

Same issue here:
@angular/cli: 1.4.3
node: 8.5.0
OS: 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

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

@filipesilva

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

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

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]

Angular CLI: 1.5.2
Node: 7.10.0
OS: win32 x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, 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
@schematics/angular: 0.1.5
typescript: 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]

Angular 5

Time: 413322ms
chunk {0} polyfills.1970941146babc162eea.bundle.js (polyfills) 99.8 kB [initial] [rendered]
chunk {1} main.14b317fb1264dafeb9ad.bundle.js (main) 3.96 MB [initial] [rendered]
chunk {2} styles.1d741fb54f277aec9a5f.bundle.css (styles) 738 bytes [initial] [rendered]
chunk {3} inline.51acfa358278247dad6c.bundle.js (inline) 1.45 kB [entry] [rendered]

@HarelM

@HarelM Yeah I did build it with --prod but this is a nice desktop, so definitely faster then what you get from appveyor.

Oh ok, yeah I didn't build the openlayers branch. But I had really slow build times when using source maps when I had scss and css. But it doesn't look like you have source maps on, so maybe you're hitting a different issue?

I now see that the debug builds when using the --watch flag in angular 7 are now significantly slower (about 10-15 seconds instead of 2-3). I'm considering downgrading back to 6... :-(

TL;DR: use increase-memory-limit package.
After a long trial and error I got to this issue: #5618 which started to happen on my builds.
I'll post a nice solution in the issue above, but apparently allowing node to have more memory reduces the build time significantly - build that was taking 43 minutes now finishes in about 5 minutes! :-)))
Hope this will help others as well.

@thenslerse

@thenslerse, sorry to necro-tag you here, but were you by chance using semantic-ui in this project? I get the exact same two warnings in my app.

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

angular universal is too slow to build, takes more than 20-30 mins to build and its not smooth to build and release. cant it be simplified ? I do the client build , then it does a server build, then again it will do a webpack to package a server.js which goes with all plugins that we add up , close to 24-30 mb single file. definitely needs a simplified way or fast build flow.

@Brandon-Born

@Brandon-Born Thank you!!!

I cannot even compile a small boilerplate-based project (angular-material, a 2-3 dozen very small modules, <5k LoC total) on a 1gb ram EC2 instance, even with every possible memory intensive option disabled:

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

Even with all these flags disabled, on my local machine this takes about 1.2gb of ram and about 30 second to build on an i7 based machine. Unacceptable.

@skylarmb

@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. ;)

@alberto-chiesa

@alberto-chiesa (trolling accepted :-)) Whilst there are no real benchmarks for such processing from the angular team, we can clearly see severe regression whilst compiling. An angular 7 project with a similar amount of files to a Angular 5 one takes 5x as long here on our development environments. It should also be noted that this is after memory and other optimizations, without those it was taking nearly 8x as long. We've gone backwards here.
Both Jenkins boxes have similar capabilities and enough resources for a standard compile.
Angular 7 is very slow in its compilation times, there's enough evidence on this post alone for that.
The unacceptable part is that development teams are being held up, boxes overloaded and it looks generally inefficient.
A couple of files as the poster suggests should take no longer than the Sass build, which for us is around 5s. Casting my mind back over the years of compilation, I don't think we are being unreasonable with our demands here.

@inthegarage

@inthegarage I'm not saying that there are no problems. I'm following this thread from the very beginning. I'm just saying that considering unacceptable that the Angular build requires more than 1 GB of RAM is naive. The issue is time: if the build is 5x slower, it's a problem (a huge one). But, if I can get the same build time throwing in more RAM, it becomes less of a problem.
Again, I don't want to troll anyone, and I'm well aware of long build times, but the build hardware target can't be "a 1gb ram EC2 instance". If you say: "build time is too slow", I'm 100% with you.
If you say "build takes too much RAM", I can just say "it would be nicer if it took less, but I really don't care that much".
I hope I have clarified this point. No trolling intended :)

@alberto-chiesa

@alberto-chiesa Agreed, there are some naive assumptions and when an IDE can gamefully hog 3GB+, to expect a compiler to use anything less is not realistic. All points clarified.
I also wish there was more urgency and activity with this problem. We seem to be in a "Jam tomorrow" situation. 1st it was wait for terser, second it was try angular 7, then mess about with some settings. Nothing has reduced the build times correctly and that's very frustrating.

Hi all,

After upgrade all the dependencies our compilations times are significantly increased, from ~2min to more than 25min (we have not waited so long).

Checking which dependency have the problem, we found the last version of Terser. We solve the problem fixing it to the 3.8.1.

Hey all,

There were two performance regressions recently that affected 7.x.

The first was in CLI 7.0 was affected by #12646, fixed by angular/angular#26734 and microsoft/TypeScript#28028.

Using at least typescript@3.1.6, @angular/core@7.0.2 and `@angular-devkit/build-angular@0.10.7 as per #12646 (comment) should take care of it.

CLI 7.1 was affected by #13102, which will be fixed by #13309, and should be out in next patch versions of the CLI build system (@angular-devkit/build-angular@0.11.5).

I think that in the past having this single issue for all performance related problems was useful, but it's not as useful anymore. More than a year has passed with a lot of new versions of Angular CLI in between then and now.

During that time a number of performance regressions came up, were fixed, and new ones came up. Having all the feedback in a single thread makes it hard to get meaningful reports, or to inform people of what versions the regressions that affect them were fixed.

At the time of writing this comment, there are 116 hidden comments:

Having so many hidden comments makes it hard for people to find information in anything but the latest comments. But on the other hand I don't think most people would go through all of the comments anyway. New users that see this thread mostly read the first and latest comments and lose things said in between.

So instead of having this mega-issue, we'll try to have current high impact performance issues pinned at the top of the issue tracker:

Generally speaking, if you are using the latest version of the CLI build system (that's @angular-devkit/build-angular and should be on your package.json) and notice a performance problem, please check the pinned issues. If you don't see anything performance related there, please open a new one.

Another thing to keep in mind is memory usage, which has a similar issue in #5618. Bigger projects take more memory to build, and when you are close to the memory limit performance may suffer. Please bear in mind that project size is not only your source code, but also includes all of the libraries you use.

Please check my comment in #5618 (comment) to see how you can increase the memory limit.

So for the reasons stated above (high volume of comments, hidden comments, hard to report and inform people) I'm also locking this issue to prevent this comment from being lost as new comments come in.

Thank you to everyone that reported and helped diagnose these performance problem. If you encounter any new ones, please open a new issue so we can give that specific regression our full attention and provide a resolution for it.

Navigation Menu

Repository navigation

Build with "ng -prod" is extremely slow #6795

Bug Report or Feature Request (mark with an `x`)

Versions.

Repro steps.

670222ms vs 62809ms is a huge difference

The log given by the failure.

Desired functionality.

143 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Build with "ng -prod" is extremely slow #6795

Description

Bug Report or Feature Request (mark with an x)

Versions.

Repro steps.

670222ms vs 62809ms is a huge difference

The log given by the failure.

Desired functionality.

Activity

ankeshdave commented on Jun 25, 2017

filipesilva commented on Jun 27, 2017

elvisbegovic commented on Jun 28, 2017

GoNode5 commented on Jun 29, 2017

hoangit21 commented on Sep 21, 2017

billdwhite commented on Sep 27, 2017

billdwhite commented on Sep 28, 2017

ShadowManu commented on Oct 28, 2017

mko commented on Nov 9, 2017

thatisuday commented on Nov 17, 2017

gozeon commented on Nov 23, 2017

KissBalazs commented on Nov 30, 2017

143 remaining items

hahn-kev commented on Dec 1, 2018

HarelM commented on Dec 1, 2018

HarelM commented on Dec 3, 2018

jamesona commented on Dec 4, 2018

muthufmass commented on Dec 10, 2018

yeahrow commented on Dec 14, 2018

skylarmb commented on Dec 17, 2018

alberto-chiesa commented on Dec 21, 2018

inthegarage commented on Dec 21, 2018

alberto-chiesa commented on Dec 21, 2018

inthegarage commented on Dec 21, 2018

rafa-suagu commented on Dec 23, 2018

filipesilva commented on Dec 27, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Bug Report or Feature Request (mark with an `x`)