Build with "ng -prod" is extremely slow

[ankeshdave]

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.

[ankeshdave]

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

[filipesilva]

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.

[elvisbegovic]

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

[GoNode5]

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

[hoangit21]

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

[billdwhite]

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

[billdwhite]

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

[ShadowManu]

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

[mko]

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

[thatisuday]

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

[gozeon]

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]

[KissBalazs]

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]

[filipesilva]

1.6.0 should improve this situation by updating to a version of webpack that has a fix for production builds. Can you update to 1.6.0 and tell me if it's better?

Production builds will always take longer than dev builds though. There's multiple optimization passes that take a long time to provide with smaller bundles.

[alberto-chiesa]

After upgrading to 1.6.0 I went from ~55 secs to ~45 secs for a small project, without css processing. It seems there is an improvement. I don't dare to say it's too significant, but it's a step in the right direction. Btw, is there a recommended upgrade path? I just updated package.json, removed node_modules and package-lock.json and npm installed everything from scratch: without a clean and reinstall nothing would work.

[GoNode5]

@filipesilva no luck time: 167712ms .. ng build --prod
Angular CLI: 1.6.0
Node: 8.7.0
OS: win32 x64
Angular: 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
@schematics/angular: 0.1.10
@schematics/schematics: 0.0.10
typescript-string-enums: 0.3.5
typescript: 2.6.2
webpack-dev-middleware: 1.12.2
webpack-dev-server: 2.9.7
webpack-merge: 4.1.1
webpack-sources: 1.1.0
webpack: 3.10.0

[mvsrinivasan]

Same issue Production Build taking too long to finish
Date: 2017-12-08T19:13:41.142Z
Hash: f6074f34cd93840962b9
Time: 347917ms
angular/cli: 1.5.0
angular/material: 5.0.0-rc0
angular-devkit/build-optimizer: 0.0.32
angular-devkit/core: 0.0.20
angular-devkit/schematics: 0.0.35
ngtools/json-schema: 1.1.0
ngtools/webpack: 1.8.0
schematics/angular: 0.1.2
typescript: 2.6.1
webpack: 3.8.1

[rodrijuarez]

Same issue here:

Time: 565883ms

@angular/cli@1.6.0 and Angular 5.1.0

[rezonjov]

on my case it takes a whooping 42 mins to finish

[ScottSpittle]

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

[dstapp]

Same here, taken 160s before, now it takes 390s with these params: node_modules/@angular/cli/bin/ng build --output-path=build/default/ --target=production --sourcemap

[filipesilva]

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

[filipesilva]

@rezonjov @ScottSpittle @dprandzioch are you using Angular 5.x?

[mvsrinivasan]

Partial relief with --build-optimizer=false and cli 1.6

Date: 2017-12-11T16:38:33.792Z
Hash: e0338ceb997073672491
Time: 224756ms (vs 347917ms on cli 1.5)
chunk {0} polyfills.5331a70a99045b106003.bundle.js (polyfills) 61.2 kB [initial] [rendered]
chunk {1} styles.64f371138d201ab1d186.bundle.css (styles) 367 kB [initial] [rendered]
chunk {2} main.18c151adc1813fa3ddd7.bundle.js (main) 155 kB [initial] [rendered]
chunk {3} vendor.fe2debb1be57f2ba9fa3.bundle.js (vendor) 1.21 MB [initial] [rendered]
chunk {4} inline.2b90f1f684dd564677bf.bundle.js (inline) 1.45 kB [entry] [rendered]

[ScottSpittle]

@filipesilva Angular 5.1.0 and CLI 1.6

[iCodr8]

@jpsk Thank you for your solution in #6795 (comment)

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

[robert-king]

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..

[kellycrowther]

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

[hbarve1]

as by reading all the comments and seeing my own angular 6 build time, I'm concluding that UglifyJSPlugin at 92% is taking most of the time and RAM as well, it is consuming more that 2GB of RAM for just one build.

[nirdshabo]

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

[aldrindizonh]

same issue :(

Date: 2018-10-15T09:17:21.275Z
Hash: a8e9f7577a381cf027bd
Time: 338960ms
chunk {0} 0.e38e03f2d9c6fd65370c.chunk.js (common) 1.29 MB [rendered]
chunk {1} 1.35b3fdbd653e9c99e87e.chunk.js () 168 kB [rendered]
chunk {2} 2.78c04f64dba92e87b001.chunk.js () 12.7 kB [rendered]
chunk {3} 3.ef5382adf15030bf4d7f.chunk.js () 41.1 kB [rendered]
chunk {4} 4.ac5e7a11066bd3bce58a.chunk.js () 713 kB [rendered]
chunk {5} 5.261500741b47979be46e.chunk.js () 867 kB [rendered]

[DaveLomber]

Same issue on OS X,
last week it was around 10 mins but then something happened and now it's around 50 mins..
That's annoying...
Going to try what @kellycrowther proposed

[negberts]

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?

[filipesilva]

We had a particularly nasty regression with 7.0 listed as #12646. The main problem there should be fixed by using @angular/core@~7.0.2 and typescript~@3.1.5.

@negberts not sure what's happening in your project really. Is it open source, or somewhere I could look at?

[artaommahe]

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

[negberts]

@artaommahe that's probably what I meant. ;-) But to be honest, I have the experience that the --aot=false version is actually starting up faster.. Not very strange I think if you compare the total size of the bundles…

@filipesilva unfortunately it is not :-( But all packages are up-to-date. I've attached the build outcomes. You need anything else? Angular.json? Package.json?

ngbuildcompare.xlsx

[awerlang]

@negberts aot precompiles the HTML templates into straight forward js files which keep the view updated. These are larger than the templates themselves, so there's a point where the combined size surpasses the size of the runtime compiler.
It saves time at runtime because it's a step done in advance.

But you pointed out the bundles are so much bigger you consider the non-aot is faster to startup. Which may be true for uncached assets, plus the difference in parsing a larger file. I build into a single bundle, so your experience with so many bundles ought to be different.

I suggest you compare these options on different devices as well. Mobile and desktop, and keep the one that perform better.

[HarelM]

Since recent versions I can't use appveyor CI no more since the build runs more than an hour.
I've updated to latest version (from 6 to 7) hoping it would improve but it just got worse.
I've tried to use build-optimizer=false but the build fails (What??).
I'd love for some insights, I'm desperate...
Code can be found here:
https://github.com/IsraelHikingMap/Site
Appveyour build can be found here:
https://ci.appveyor.com/project/IsraelHikingHost/site
The relevant branch which I'm currently working on is called openlayers.
Please let me know if you need anything else.
Production build used to run for about 10 minutes in angular version 4-5 I think...
I've sent a heart breaking mail to appveyor and asked them to increase the timeout, hope they would help out, but I would really like my build to take less time, this is not a huge app...

[hahn-kev]

@HarelM 2 things you could try that seemed to help me. Upgrade @angular-devkit/build-angular you're on version 8, but version 10 is out (not sure why this isn't updated when you update the cli or anything else)

You're also mixing scss and css. Which doesn't seem like it would be a big deal, but when I converted all my css files over to scss, I saw my build time drop quite a bit.

I just tried it out on your repo and didn't see much change, but the build only took a little over a minute for me.

[HarelM]

@hahn-kev Thanks for the super quick response!
As can be seen here on the openlayers branch the devkit version is 0.11:
https://github.com/IsraelHikingMap/Site/blob/dd78814bc11b86fc66157943e79e3a3d8e85488d/IsraelHiking.Web/package.json#L60
I'll try to migrate all my css file to scss, although I have a generated one from icomoon which I don't fancy migrating every time I change it, but if it will reduce the build time I'll give it a go.

but the build only took a little over a minute for me.

Did you build it with --prod?
In any case, the appveyor servers are limited on resources and it is taking a very long time there. They were kind enough to extend the timeout to 90 minutes just now, I hope it will be enough...

[hahn-kev]

@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?

[HarelM]

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... :-(

[HarelM]

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.

[jamesona]

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

[muthufmass]

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.

[yeahrow]

@Brandon-Born Thank you!!!

[skylarmb]

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.

[alberto-chiesa]

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

[inthegarage]

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

[alberto-chiesa]

@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 :)

[inthegarage]

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

[rafa-suagu]

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.

[filipesilva]

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.