It takes forever in "92% chunk asset optimization" can it be cached or disabled?

[marcalj]

Bug Report or Feature Request (mark with an x)

- [x] feature request

Versions.

@angular/cli: 1.0.0-rc.2
node: 6.9.2
os: darwin x64
@angular/common: 2.4.10
@angular/compiler: 2.4.10
@angular/core: 2.4.10
@angular/forms: 2.4.10
@angular/http: 2.4.10
@angular/platform-browser: 2.4.10
@angular/platform-browser-dynamic: 2.4.10
@angular/router: 3.4.10
@angular/cli: 1.0.0-rc.2
@angular/compiler-cli: 2.4.10

Desired functionality.

assets optimization it rarely changes when you only do coding, and specially for my project it takes 2-5 minutes each time. So it's killing my productivity. With "--verbose" it doesn't show me any specific files which I could remove temporally to speed up the process of compiling...

Hash: 51ba5014dae3bd179ab9                                                                 
Time: 395021ms
chunk    {0} main.bundle.js, main.bundle.js.map (main) 10.8 MB {4} [initial] [rendered]
chunk    {1} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 278 kB {5} [initial] [rendered]
chunk    {2} styles.bundle.js, styles.bundle.js.map (styles) 751 kB {5} [initial] [rendered]
chunk    {3} scripts.bundle.js, scripts.bundle.js.map (scripts) 362 kB {5} [initial] [rendered]
chunk    {4} vendor.bundle.js, vendor.bundle.js.map (vendor) 4.44 MB [initial] [rendered]
chunk    {5} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]

Thanks.

[Meligy]

This is Webpack output, not an awesome one.

Assets here do not refer to Angular CLI assets. They refer to Webpack chunk files. This is where a big part of the Webpack processing of files happens. That's why it's a long-ish one.

There's a very long discussion about the whole build speed topic here #1980.

What you are seeing is certainly crazy though (and very unusual from experience with many projects), regardless of this specific message.

[clydin]

can you provide the command line used to perform the build?

[marcalj]

@clydin I'm using ng serve --proxy-config proxy.config.json --aot --watch false --verbose or ng build --aot.

I'm also compiling without Ahead of Time (AoT) though... but my project is big...

[marcalj]

Without AoT the build time is reduced considerably:

40207ms building modules                                                                   
293ms sealing
17ms optimizing
1ms basic module optimization 
0ms module optimization 
1000ms advanced module optimization
58ms basic chunk optimization       
0ms chunk optimization 
4ms advanced chunk optimization 
0ms module and chunk tree optimization 
0ms module reviving 
60ms module order optimization
9ms module id optimization 
0ms chunk reviving 
11ms chunk order optimization
51ms chunk id optimization
186ms hashing
4ms module assets processing 
368ms chunk assets processing
10ms additional chunk assets processing
0ms recording 
0ms additional asset processing 
11447ms chunk asset optimization
106ms asset optimization
784ms emitting
Hash: 52784939e9af576aa850
Version: webpack 2.2.1
Time: 54662ms

But I get more errors with AoT enabled, that's why I want to use it while building.

[marcalj]

Now I need to expand node's heap memory size to compile with AoT. It now uses 5.5GB of RAM to compile with AoT... :(

node --max_old_space_size=8192 ./node_modules/.bin/ng build --aot
Hash: 2013b35185f990a8e57f                                                                 
Time: 373584ms
chunk    {0} main.bundle.js, main.bundle.js.map (main) 12 MB {4} [initial] [rendered]
chunk    {1} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 278 kB {5} [initial] [rendered]
chunk    {2} styles.bundle.js, styles.bundle.js.map (styles) 751 kB {5} [initial] [rendered]
chunk    {3} scripts.bundle.js, scripts.bundle.js.map (scripts) 362 kB {5} [initial] [rendered]
chunk    {4} vendor.bundle.js, vendor.bundle.js.map (vendor) 4.44 MB [initial] [rendered]
chunk    {5} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]

[alexciesielski]

+1, experiencing same problem with --aot enabled on CLI 1.0.0 and Angular 4.
It takes over 3 minutes to compile, most of it is at 92% chunk asset optimization.

> ng serve --proxy-config proxy.conf.json --open --aot

** NG Live Development Server is running on http://localhost:4200 **
 12% building modules 21/25 modules 4 active ...ode_modules/style-loader/addStyles.jswebpack: wait until bundle finished: /
 94% asset optimizationwebpack: wait until bundle finished: /
Hash: b569b293e489e6c84a01
Time: 192655ms
chunk    {0} 0.chunk.js, 0.chunk.js.map 3.84 MB {1} {2} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {1} 1.chunk.js, 1.chunk.js.map 2.23 MB {0} {2} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {2} 2.chunk.js, 2.chunk.js.map 1.91 MB {0} {1} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {3} 3.chunk.js, 3.chunk.js.map 1.73 MB {0} {1} {2} {4} {5} {6} {7} {9} [rendered]
chunk    {4} 4.chunk.js, 4.chunk.js.map 1.74 MB {0} {1} {2} {3} {5} {6} {7} {9} [rendered]
chunk    {5} 5.chunk.js, 5.chunk.js.map 1.63 MB {0} {1} {2} {3} {4} {6} {7} {9} [rendered]
chunk    {6} 6.chunk.js, 6.chunk.js.map 1.6 MB {0} {1} {2} {3} {4} {5} {7} {9} [rendered]
chunk    {7} 7.chunk.js, 7.chunk.js.map 1.57 MB {0} {1} {2} {3} {4} {5} {6} {9} [rendered]
chunk    {8} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 231 kB {13} [initial] [rendered]
chunk    {9} main.bundle.js, main.bundle.js.map (main) 179 kB {12} [initial] [rendered]
chunk   {10} styles.bundle.js, styles.bundle.js.map (styles) 576 kB {13} [initial] [rendered]
chunk   {11} scripts.bundle.js, scripts.bundle.js.map (scripts) 858 kB {13} [initial] [rendered]
chunk   {12} vendor.bundle.js, vendor.bundle.js.map (vendor) 1.72 MB [initial] [rendered]
chunk   {13} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]
webpack: Compiled successfully.

Without --aot it takes around 20 seconds.

[hccampos]

For now, compiling AoT is unusable, and the Angular team knows it. Apparently they are working hard to make it faster, but it will always be significantly (?) slower than just going through the Typescript compiler.

Another thing that makes compilation extremely slow (and use a lot of memory) is having source maps enabled. In most situations we compile and develop without sourcemaps enabled because of how slow the rebuilds get when they are enabled. It is not ideal, but there is a lot of work that has to go into Webpack (especially) to make them fast.

Wepack has some cheaper source map options but they don't work properly with Typescript, so no go there either.

[clydin]

AOT is not currently intended for use during development. It is in essence a production optimization similar in some respects to minification or compression.

[marcalj]

@clydin I've used to detect bootstrap errors only present while executing (not compiling). Before writing tests it's very useful.

[DrMueller]

@clydin I have the 92% problem using ng test, which means Karma doesn't detect changes and I have to restart ng test every time. Is that the same problem or just a coincidence?

[filipesilva]

The 92% asset optimizing is a webpack thing, yes. I second what @hccampos and @clydin said: it is unadvisable to use --aot for development right now, as it will be too slow. The Angular team is working hard to make it fast enough to use at all times, but we're not there yet.

@DrMueller ng test currently does not make use of some optimizations we have in ng build and that causes rebuilds to be slow. That is being tracked in #5423, with a tentative solution in #6160.

[SchnWalter]

I had the same performance issue and I saw that by adding --sourcemap=false to ng serve and ng test things started to work a lot faster.

ng serve --sourcemap=false

[cevarief]

@SchnWalter This reduces significantly from 11 seconds to 6 seconds. Awesome. Any affect to development by turning off sourcemap?

[tytskyi]

Any affect to development by turning off sourcemap?

@cevarief
If you want to use debugger; or explore stack trace, then you will get mapping to unreliable lines of source code.
Which is acceptable when you don't want to debug. Otherwise if you want to debug you just turn it on with sourcemaps again.

[vance]

our AOT build takes 26 seconds. Is there a way to gain insight into what it is building at this step?

[ctrl-brk]

AOT takes some time but I only use it for production builds so it's OK.
ng serve takes a bit of time (less than AOT) initially but then it's pretty fast on rebuilds.
The only problem I still have is that when I change some interface definition it doesn't pick it up. It will rebuild but then complain that some field doesn't exist on the interface. You have to kill it and run ng serve again to make changes work.

[karthik04]

Disabling sourcemap made things much faster for me,

ng serve --sourcemap=false

[vance]

I guess I should have been more specific as this is part of ng test command from the angular cli. It is really frustrating running unit tests and having to wait 30 seconds...

[vance]

That slow 36-second ng test mentioned earlier was using CLI version 1.0. Using the latest 1.3.0-rc.5 is even slower. 2x time for compilation, 2x time for chunk asset optimization step. Using this version it takes 56 seconds before unit tests can run. If you turn on build-optimization it takes a whopping 98 seconds... We need a way to disable it for ng-test and/or get more verbose output during the chunk asset phase.

[tzehetner]

"ng serve --sourcemap=false" reduced the rebuild time from 20 seconds to 2 seconds in my case.

[egervari]

My AOT build takes 362 seconds on Google's Compute engine, 1 CPU, 6.5 Gig Ram. Adding more cpus hasn't really made any difference.

On my personal computer, it takes about 210 seconds to build the app, which is strange, because it's a 5-year old i7-3660 (OC'd to 4.2ghz, but still).

Honestly, this makes deployment frustrating, especially when you get a Javascript Heap Error and you've been waiting 6 minutes just to discover that.

As an aside, I think ng build's with aot should set the node memory for you, or you really ought to add this to your default package.json just to make things easier for people:

"build-prod": "node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot",

[gangsthub]

92% chunk asset optimization

I'm already ordering some! 😂

[allanesquina]

Running into the same issue here, it stops in 94%. Can we customize the shirt @gangsthub? 😄

[SchnWalter]

You should stop complaining, update your Angular CLI, fix your AOT build warnings and use AOT also for debugging, since it now supports debugging:

ng serve --aot

And try to keep up with the Angular CLI releases, things are getting better day by day.

P.S. Thanks to everyone working on this!

EDIT: With AOT the initial build is slow, subsequent builds are a lot faster.

[inthegarage]

I can confirm moving to terser has done the trick as described by @mlwilkerson , the short simple steps are:

npm i terser --save-dev

and then

  "resolutions": {
    "uglify-es": "npm:terser"
  }

In your package.json

My build reduced to less than a minute. (from over several mins)

[clydin]

Please also note that version 7.0 of the CLI now uses terser by default. No additional steps are necessary.

[diekotto]

Hi, i fixed this issue in my work pc using powershell instead wsl. I don't know if any of you are using the linux subsystem but the cpus are locked, you cannot parallelize, so using powershell for build and serve boosted up my times.
I am talking about: ctr+c after +40minutes to -2minutes.

[rbluethl]

Can anybody tell why this issue has been closed? Our release build still takes literally years to complete. Always hangs at "92% chunk asset optimization".

[diekotto]

My issue with this was solved when I finished using Ubuntu subsystem as npm default manager, it doesn't parallelize and this task last forever.
I moved to powershell.

[gangsthub]

Can anybody tell why this issue has been closed? Our release build still takes literally years to complete. Always hangs at "92% chunk asset optimization".

@rbluethl, 92% is about where UglifyJSPlugin was being used. Updating to Angular 7 will help because a different plugin (Terser) is used. Also, you may be going out of RAM. Happened to me with a 4GB server at the beginning.

I'm still with Angular 6. This is what I'm using in production these days:

> ng build --prod --extract-css=true --sourceMap=false --aot --build-optimizer=true --vendor-chunk=true

And in development:

> ng serve --progress --open --sourceMap=true --optimization=false --aot --vendorChunk=true

• --optimization=false disables the minification using UglifyJSPlugin, wich will help you.
• And notice that it is recommended to use --aot in both processes.
• --prod --aot will reduce the build time and output size ;). See my previous comment: It takes forever in "92% chunk asset optimization" can it be cached or disabled? #5775 (comment)

[diekotto]

-- prod is - - aot already.

[Dzhuneyt]

@gangsthub I tried --optimization=false on our internal project (which takes 2:40 minutes generally to build). It didn't bring any improvement. In fact, it increased the build time to 2:44.

It's important to note that we are using ng build --watch=true though, not ng serve (your example). Maybe the flag is only valid for the serve subcommand.

[gangsthub]

You are right, @DiegoMGar. --prod includes --aot according to the documentation.
@Dzhuneyt, I might not be getting your issue correctly: why are you using build + watch in development? I don't think it's what it is thought for. Build makes a production bundle by default: https://angular.io/cli/build

[Dzhuneyt]

@gangsthub because we have a fairly complex project that requires NGINX, Apache and forwarding these two to a static directory where the frontend source code is accessible (/dist). The "lite server" of Angular doesn't do the trick.

[tomardern]

This seems to be more of an issue if you enable source maps. The following setup/commands work under Angular 7:

SourceMap settings in angular.json

"sourceMap": {
	"hidden": true,
	"scripts": true,
	"styles": true
}

Using the following command:

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --es5BrowserSupport=true --prod=true --aot --build-optimizer=true --output-hashing all --extract-css=true --output-path=./tmp/dist

It will stick at 92% for a while, but does eventually build.

[ishaan-puniani]

Well, in my case the the process was terminating because of insufficient memory.
I enabled swapping on build server and then it works perfectly fine.

[aijazkhan81]

Can we open this issue back again?

[vitaminac]

I got this error when i built in docker in Window, i changed the limit of memory to 4GB in virtualbox configuracion and it works for me.

[Stradivario]

I think we are facing this issue since Reflect metadata API is now part of the build process of angular, so we will have more computation input but the application will be more faster.I am trying to use some work around building it with Parcel since 1 GB ram is really not enough building complex angular project these days even with 4 GB of swap...

It will be really useful if we have cache output from the build so we can then attach this cache to Docker container and only the changes will be build instead the whole application.Yes some will say it will trigger more problems with cache but it depends on how well is written ;)

[geniusunil]

Angular-cli 7.1.2 using terser only, removed uglify. The problem is still the same. I don't understand why this issue is closed.

[ssarkisy]

MacBook Pro 2017 (max configuration). On my colleague's laptop, it took like 6 times longer.
Angular-cli 7.3.8
ng build --prod --aot

Date: 2019-05-22T14:17:10.865Z
Hash: c46f53e11f136ebcccaf
Time: 252612ms
chunk {0} common.afc1032bf3c4b8275ad0.js (common) 13.3 kB [rendered]
chunk {1} 1.a15ce621172a345de3fb.js () 17.7 kB [rendered]
chunk {2} 2.2f5ed724319337a8e568.js () 35.4 kB [rendered]
chunk {3} 3.60e537acc75ac058b27c.js () 18.4 kB [rendered]
chunk {4} runtime.579f6773a2b26d94db5d.js (runtime) 3.55 kB [entry] [rendered]
chunk {5} 5.347c1f3685ec3ba82396.js () 22.5 kB [rendered]
chunk {6} main.9181a4cb2e65813f8502.js (main) 4.3 MB [initial] [rendered]
chunk {7} polyfills.7b3fb56fc82120d2029f.js (polyfills) 61.7 kB [initial] [rendered]
chunk {8} styles.268c785458aec578546e.css (styles) 326 kB [initial] [rendered]
chunk {9} 9.cf61d9ddb5622467f3f3.js () 31 kB [rendered]
chunk {10} 10.0cd72c145b577e65cf28.js () 5.3 kB [rendered]
chunk {11} 11.9dfeb2dd944fe80224cf.js () 98.6 kB [rendered]
chunk {12} 12.8aa7c4e6cdd6615f2014.js () 7.07 kB [rendered]
chunk {13} 13.8999e86ed963ef839840.js () 29 kB [rendered]
chunk {14} 14.8cf84a196f45ed341ce0.js () 5.31 kB [rendered]
chunk {15} 15.d313fabcfc0d0a86d25d.js () 18.7 kB [rendered]
chunk {16} 16.3bb6114bc3541835e4a0.js () 6.38 kB [rendered]
chunk {17} 17.7c5dbc1fbe2336666081.js () 18.4 kB [rendered]
chunk {18} 18.709082325c1f7cbbd1b9.js () 5.32 kB [rendered]
chunk {19} 19.f75679cd15753e642ace.js () 5.32 kB [rendered]
chunk {20} 20.ead991d5d12b29a5c046.js () 23.2 kB [rendered]
chunk {21} 21.b19be2caaa1019c1d5a8.js () 5.32 kB [rendered]
chunk {22} 22.b8710a26bd79a8f2d9d5.js () 6.36 kB [rendered]
chunk {23} 23.31688d97f4b9eb3e8b7d.js () 5.31 kB [rendered]
chunk {24} 24.4ddab1995018ff5b7989.js () 6.34 kB [rendered]
chunk {25} 25.604287facfdf4d4ef67c.js () 5.34 kB [rendered]
chunk {26} 26.7da604b902f6832785fa.js () 38 kB [rendered]
chunk {27} 27.bdbbe5cfd351f05fb927.js () 44.5 kB [rendered]
chunk {28} 28.8d1645bad2f255229883.js () 6.36 kB [rendered]
chunk {29} 29.cae28ed727cef99550da.js () 18.2 kB [rendered]
chunk {30} 30.0757b5c5e76726394c96.js () 36.1 kB [rendered]
chunk {31} 31.f70fcde5f461f52b298f.js () 24.6 kB [rendered]
chunk {32} 32.f6a13d5d31d0811486c1.js () 5.32 kB [rendered]
chunk {33} 33.2f77b41e9e23b60d7a4c.js () 5.34 kB [rendered]
chunk {34} 34.75833ca150c5c8fdd6bd.js () 5.32 kB [rendered]
chunk {35} 35.c57bcf3e34e617dfabc6.js () 6.35 kB [rendered]
chunk {36} 36.5fa2d920b12f46a07172.js () 6.35 kB [rendered]
chunk {37} 37.a394ec89e4d0bf0d72a6.js () 6.36 kB [rendered]
chunk {38} 38.b34cc886a6eaa8be42a7.js () 5.37 kB [rendered]
chunk {39} 39.ffa574e6aed984aef474.js () 18 kB [rendered]
chunk {40} 40.30389c2e462dcd3da05f.js () 6.36 kB [rendered]
chunk {41} 41.8e53571d710cc118d3a7.js () 6.35 kB [rendered]
chunk {42} 42.1489d4775a8537d8cf61.js () 23 kB [rendered]
chunk {43} 43.d986a7e4817dc6559e1c.js () 30.8 kB [rendered]
chunk {44} 44.416ca46085d6452e2aae.js () 56.9 kB [rendered]
chunk {45} 45.807652b30c9ae86f81df.js () 48.8 kB [rendered]
chunk {46} 46.0b5ed5eb48ede6e2a472.js () 59.3 kB [rendered]
chunk {47} 47.23e8ca78a06e5de3029b.js () 51.2 kB [rendered]
chunk {48} 48.61a69980e6f487c0562c.js () 20.1 kB [rendered]
chunk {49} 49.b10ef4d1f7cad8e72cd1.js () 20.8 kB [rendered]
chunk {50} 50.9ad9e94f088ad56d6dd8.js () 23.6 kB [rendered]
chunk {51} 51.121732df2f2a4fcee042.js () 5.32 kB [rendered]
chunk {52} 52.d288a7457b03303af53c.js () 5.3 kB [rendered]
chunk {53} 53.a26d29e5795cb20db1c3.js () 36.1 kB [rendered]
chunk {54} 54.985c05de0e4736723d6e.js () 5.33 kB [rendered]
chunk {55} 55.577c2d061a42d919bbce.js () 6.67 kB [rendered]
chunk {56} 56.46d02993596d7be5fcc6.js () 42.5 kB [rendered]
chunk {57} 57.f182f866ab2ff39159a8.js () 58.9 kB [rendered]
chunk {58} 58.aac5f7b34340b2766b37.js () 63.3 kB [rendered]
chunk {59} 59.c6d03497f0a9fc3e2920.js () 5.3 kB [rendered]
chunk {scripts} scripts.df23d47c2e627c65cf17.js (scripts) 262 kB [entry] [rendered]

[Ni55aN]

Angular 8. The same issue

[Ni55aN]

Running with node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot doesn't help

[bleuscyther]

reduce --max-old-space-size=8192 , i had to use --max-old-space-size=4096 or lower : 2048, 1024... depending on the host

[inthegarage]

@bleuscyther Really only any use for small projects, will seriously impair large projects. Still if you have a small project, then this is the setting for you.

[kdubious]

@filipesilva This seemed to be an issue you understood well. Is the issue back? Should this be re-opened?

[renatop7]

I'm using WSL Ubuntu 18.04, tried everything others commented in this thread and I can't build my Angular 7 project.
Eventually I gave up and now I'm using powershell to build it...

[majid-rehman]

This help me solve the problem on t2.micro ,, max time 2 minutes

create swap

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=3024
sudo /sbin/mkswap /var/swap.1
sudo chmod 600 /var/swap.1
sudo /sbin/swapon /var/swap.1

If you need more or less than 3024 then change that to something you want.

To enable it by default after reboot, add this line to /etc/fstab:

/var/swap.1 swap swap defaults 0 0

After doing all these run below command

ng build --prod --build-optimizer=false

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}