Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
marcalj opened this issue Mar 31, 2017 · 84 comments
Closed

Comments

@marcalj
Copy link

marcalj commented Mar 31, 2017

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
Copy link
Contributor

Meligy commented Mar 31, 2017

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
Copy link
Member

clydin commented Mar 31, 2017

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

@marcalj
Copy link
Author

marcalj commented Apr 3, 2017

@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
Copy link
Author

marcalj commented Apr 3, 2017

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
Copy link
Author

marcalj commented Apr 3, 2017

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
Copy link

alexciesielski commented Apr 11, 2017

+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
Copy link

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
Copy link
Member

clydin commented Apr 11, 2017

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
Copy link
Author

marcalj commented Apr 11, 2017

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

@DrMueller
Copy link

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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

@tytskyi
Copy link

tytskyi commented Jul 14, 2017

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
Copy link

vance commented Aug 4, 2017

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

@ctrl-brk
Copy link

ctrl-brk commented Aug 4, 2017

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
Copy link

Disabling sourcemap made things much faster for me,

ng serve --sourcemap=false

@vance
Copy link

vance commented Aug 7, 2017

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
Copy link

vance commented Aug 8, 2017

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
Copy link

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

@egervari
Copy link

egervari commented Dec 5, 2017

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
Copy link

92% chunk asset optimization

image

I'm already ordering some! 😂

@allanesquina
Copy link

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

@SchnWalter
Copy link
Contributor

SchnWalter commented Feb 16, 2018

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
Copy link

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
Copy link
Member

clydin commented Oct 25, 2018

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

@diekmrcoin
Copy link

diekmrcoin commented Nov 20, 2018

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
Copy link

rbluethl commented Mar 6, 2019

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

@diekmrcoin
Copy link

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
Copy link

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

@diekmrcoin
Copy link

diekmrcoin commented Mar 7, 2019

-- prod is - - aot already.

@Dzhuneyt
Copy link

Dzhuneyt commented Mar 14, 2019

@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
Copy link

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
Copy link

@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
Copy link

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
Copy link

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
Copy link

Can we open this issue back again?

@vitaminac
Copy link

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
Copy link

Stradivario commented Apr 7, 2019

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
Copy link

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
Copy link

ssarkisy commented May 22, 2019

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
Copy link

Ni55aN commented Jun 11, 2019

Angular 8. The same issue

@Ni55aN
Copy link

Ni55aN commented Jun 11, 2019

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

@bleuscyther
Copy link

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

@inthegarage
Copy link

@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
Copy link

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

@renatop7
Copy link

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
Copy link

majid-rehman commented Jul 26, 2019

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

Screen Shot 2019-07-26 at 4 27 53 PM

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests