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 · 62 comments

Comments

Projects
None yet
@marcalj

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

This comment has been minimized.

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

This comment has been minimized.

Member

clydin commented Mar 31, 2017

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

@marcalj

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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]
@ciesielskico

This comment has been minimized.

ciesielskico 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

This comment has been minimized.

hccampos commented Apr 11, 2017

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

DrMueller commented Apr 24, 2017

@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

This comment has been minimized.

Member

filipesilva commented May 4, 2017

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.

@filipesilva filipesilva closed this May 4, 2017

@SchnWalter

This comment has been minimized.

SchnWalter commented Jun 23, 2017

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

This comment has been minimized.

cevarief commented Jul 14, 2017

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

@tytskyi

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

karthik04 commented Aug 5, 2017

Disabling sourcemap made things much faster for me,

ng serve --sourcemap=false

@vance

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

tzehetner commented Oct 1, 2017

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

@egervari

This comment has been minimized.

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

This comment has been minimized.

gangsthub commented Feb 6, 2018

92% chunk asset optimization

image

I'm already ordering some! 😂

@allanesquina

This comment has been minimized.

allanesquina commented Feb 15, 2018

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

@SchnWalter

This comment has been minimized.

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.

@BigSakoLol

This comment has been minimized.

BigSakoLol commented Jul 21, 2018

Also got this problem. It takes 25 minutes to build project. Was 2-3 minutes before.

@ochadenat

This comment has been minimized.

ochadenat commented Jul 28, 2018

Same issue when deploying Angular 6 application to Heroku using ng build --prod
Getting stuck at 92% chunk asset optimization UglifyJSPlugin for at least 5 min

@nimatullah

This comment has been minimized.

nimatullah commented Jul 31, 2018

same issue with webpack production

@rwlnd

This comment has been minimized.

rwlnd commented Jul 31, 2018

This is becoming quite the running gag. Stuck on 92% chunk asset optimization UglifyJSPlugin on gitlab while it's quite acceptable when building locally, even with the --prod flag.

@sanjay2880

This comment has been minimized.

sanjay2880 commented Aug 2, 2018

it took me 1 hr to make a prod build
we are using angular 4.4.6 & my build command is
node --max_old_space_size=6048 node_modules/@angular/cli/bin/ng build --prod --aot --env=azureDev --extract-css --preserve-symlinks --named-chunks

image

@meghma

This comment has been minimized.

meghma commented Aug 2, 2018

Wish there was an acknowledgement from the Angular team about this issue and a tentative eta for solution

@hammadbinarif

This comment has been minimized.

hammadbinarif commented Aug 3, 2018

Same here, Getting stuck at 92% chunk asset optimization UglifyJSPlugin for at least 3 min

@kdubious

This comment has been minimized.

kdubious commented Aug 3, 2018

@meghma, this item is marked as closed. Maybe open a new issue?

@filipesilva Can you help us with this?

@lucboutier

This comment has been minimized.

lucboutier commented Aug 3, 2018

Had the same issue and found some details on font awesome website:

https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking

The workaround I have currently used is to create a patch.js file with the following content:

const fs = require('fs');
const common = 'node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js';

fs.readFile(common, 'utf8', function (err, data) {
  if (err) {
    return console.log(err);
  }
  var result = data.replace(/compress: {/g, 'compress: { collapse_vars: false,');

  fs.writeFile(common, result, 'utf8', function (err) {
    if (err) return console.log(err);
  });
});

And reference it in the package.json

...

  "scripts": {
    "postinstall": "node patch.js",
...

you'll have to run node/yarn install so it is triggered.

HTH

@Sebubu

This comment has been minimized.

Sebubu commented Aug 9, 2018

@lucboutier Doesn't work in my case.

@vandammeb

This comment has been minimized.

vandammeb commented Aug 9, 2018

@lucboutier no luck here either, the only thing working for now is disabling compression all together, which is not an option in my case

@mlwilkerson

This comment has been minimized.

mlwilkerson commented Aug 9, 2018

There's a workaround available for yarn builds, using an alias to replace uglify-es with terser, which includes the root cause fix for the collpase_vars issue. That might be an option for some folks here until that fix makes its way into the Webpack 4 dependencies.

Has anyone tried that for an angular-cli project?

(UPDATE Sept 26, 2018: this change will not make it into Webpack 4 deps, but the Webpack 5 roadmap includes a move to terser which has the fix.)

@vandammeb

This comment has been minimized.

vandammeb commented Aug 9, 2018

Managed to get it working by explicitly overriding all compress settings with their default values according to the docs (I have yet to figure out why that actually works though).

An update for the script from @lucboutier :

const fs = require('fs');
const common = 'node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js';

fs.readFile(common, 'utf8', function (err, data) {
  if (err) {
    return console.log(err);
  }
  var result = data.replace(/compress: {[^}]*}/g, 'compress: {\n' +
    '           arrows: true,\n' +
    '           booleans: true,\n' +
    '           collapse_vars: true,\n' +
    '           comparisons: true,\n' +
    '           computed_props: true,\n' +
    '           conditionals: true,\n' +
    '           dead_code: true,\n' +
    '           drop_console: false,\n' +
    '           drop_debugger: true,\n' +
    '           ecma: wco.supportES2015 ? 6 : 5,\n' +
    '           evaluate: true,\n' +
    '           expression: false,\n' +
    '           global_defs: {},\n' +
    '           hoist_funs: false,\n' +
    '           hoist_props: true,\n' +
    '           hoist_vars: false,\n' +
    '           if_return: true,\n' +
    '           // Workaround known uglify-es issue\n' +
    '           // See https://github.com/mishoo/UglifyJS2/issues/2949#issuecomment-368070307\n' +
    '           inline: wco.supportES2015 ? 1 : 3,\n' +
    '           join_vars: true,\n' +
    '           keep_classnames: false,\n' +
    '           keep_fargs: true,\n' +
    '           keep_fnames: false,\n' +
    '           keep_infinity: false,\n' +
    '           loops: true,\n' +
    '           negate_iife: true,\n' +
    '           // PURE comments work best with 3 passes.\n' +
    '           // See https://github.com/webpack/webpack/issues/2899#issuecomment-317425926.\n' +
    '           passes: buildOptions.buildOptimizer ? 3 : 1,\n' +
    '           properties: true,\n' +
    '           pure_funcs: null,\n' +
    '           pure_getters: buildOptions.buildOptimizer,\n' +
    '           reduce_funcs: true,\n' +
    '           reduce_vars: true,\n' +
    '           sequences: true,\n' +
    '           side_effects: true,\n' +
    '           switches: true,\n' +
    '           toplevel: false,\n' +
    '           top_retain: null,\n' +
    '           typeofs: true,\n' +
    '           unsafe: false,\n' +
    '           unsafe_arrows: false,\n' +
    '           unsafe_comps: false,\n' +
    '           unsafe_Function: false,\n' +
    '           unsafe_math: false,\n' +
    '           unsafe_methods: false,\n' +
    '           unsafe_proto: false,\n' +
    '           unsafe_regexp: false,\n' +
    '           unsafe_undefined: false,\n' +
    '           unused: true,\n' +
    '           warnings: false\n' +
    '         }');

  fs.writeFile(common, result, 'utf8', function (err) {
    if (err) return console.log(err);
  });
});

To prevent the memory issue ng build still has to be run in a context with increased memory available

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build ...

Hope still helps someone.

@gpresland

This comment has been minimized.

gpresland commented Aug 20, 2018

Currently experiencing this issue.

Angular CLI: 6.1.3
Node: 8.11.3
OS: win32 x64
Angular: 6.1.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.7.3
@angular-devkit/build-angular     0.7.3
@angular-devkit/build-optimizer   0.7.3
@angular-devkit/build-webpack     0.7.3
@angular-devkit/core              0.7.3
@angular-devkit/schematics        0.7.3
@angular/cli                      6.1.3
@ngtools/webpack                  6.1.3
@schematics/angular               0.7.3
@schematics/update                0.7.3
rxjs                              6.2.2
typescript                        2.7.2
webpack                           4.9.2

@egervari 's solution of:

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

Makes the build go from ~12 minutes to 2 seconds for me.

@Drogglbecher

This comment has been minimized.

Drogglbecher commented Aug 30, 2018

@mlwilkerson: Worked with angular-cli. Thanks for the hint 👍

@konstantinkoeppe

This comment has been minimized.

konstantinkoeppe commented Aug 30, 2018

@mlwilkerson: terser is working great - Significantly reduced build times from > 50 minutes to < 2 minutes for me.

Here's what I did (more of a temporary solution):

# Add terser to dependencies
npm install terser --save-dev

# Remove uglify-js
rm -r node_modules/uglify-js
rm -r node_modules/uglifyjs-webpack-plugin/node_modules/uglify-es

# Symlink to terser (which is fully compatible)
ln -s $(pwd)/node_modules/terser $(pwd)/node_modules/uglify-js
ln -s $(pwd)/node_modules/terser $(pwd)/node_modules/uglifyjs-webpack-plugin/node_modules/uglify-es
@tzjoke

This comment has been minimized.

tzjoke commented Aug 31, 2018

@konstantinkoeppe thanks for the script. building time decreased by 30%

@vitorrd

This comment has been minimized.

vitorrd commented Sep 4, 2018

konstantinkoeppe is the only solution I found in this thread. Great job mate.

@elie222

This comment has been minimized.

elie222 commented Sep 4, 2018

Trying to build this in a docker container. Had no luck with any of the above approaches. Always hangs at 92%.

Why did this issue get closed?

@dietergoetelen

This comment has been minimized.

dietergoetelen commented Sep 13, 2018

FYI: I'm using the linux shell on windows. When I use the linux shell it's terribly slow (didn't even wait to finish).

When I use powershell it builds in 10seconds.

@anupy

This comment has been minimized.

anupy commented Sep 14, 2018

webpack-contrib/uglifyjs-webpack-plugin#272

I found this solution node --max_old_space_size=4096 node_modules/.bin/webpack -p --progress --profile Hopefully, this will help someone.

@kdubious

This comment has been minimized.

kdubious commented Sep 14, 2018

@anupy Any tips on what we do with that line and how it will help? I don't see the connection, yet.

@Bl4ckPix3l

This comment has been minimized.

Bl4ckPix3l commented Sep 23, 2018

I had also a very slow build time from up to 20 min. But in my case, i had to optimize the imports. So, the tree shaking will not have to many to do. Especially the optimization of the fontawesome imports to deep imports solved the build time problem. Maybe this will help someone.

@inthegarage

This comment has been minimized.

inthegarage commented Oct 25, 2018

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

This comment has been minimized.

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.

@DiegoMGar

This comment has been minimized.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment