Skip to content
This repository was archived by the owner on Apr 4, 2025. It is now read-only.
This repository was archived by the owner on Apr 4, 2025. It is now read-only.

Build Optimizer increasing build time excessively #305

Closed

Description

@filipesilva

In angular/angular-cli#5618 (comment), @changLiuUNSW reported a 3x increase in build time (from ~3 to ~9 minutes) when using --build-optimizer:

Angular CLI 1.5.2 with Angular 5.0.1

ng build --prod
Time: 530465ms
chunk {0} polyfills.953b2ea9f096cadfdccc.bundle.js (polyfills) 147 kB [initial] [rendered]
chunk {1} main.e2cfa60d1ec303d72a6a.bundle.js (main) 1.77 MB [initial] [rendered]
chunk {2} styles.b49f8f5ee25381105567.bundle.css (styles) 108 kB [initial] [rendered]
chunk {3} inline.2ae12ef65c8a9f6162ba.bundle.js (inline) 1.49 kB [entry] [rendered]

ng build --prod --build-optimizer=false
Time: 163265ms
chunk {0} polyfills.cdff46cd9b1a8d656218.bundle.js (polyfills) 147 kB [initial] [rendered]
chunk {1} main.d1916123bd0e4aa2858f.bundle.js (main) 1.34 MB [initial] [rendered]
chunk {2} styles.d1f7c9f576103c62cb95.bundle.css (styles) 108 kB [initial] [rendered]
chunk {3} vendor.1fbdf23b6f274bb4005e.bundle.js (vendor) 639 kB [initial] [rendered]
chunk {4} inline.58b71d550a47f85197a5.bundle.js (inline) 1.5 kB [entry] [rendered]

#304 has possibly improved this, but needs to be verified.

@changLiuUNSW can you try with Angular CLI 1.5.5 and let us know what's the current build time please?

Likely related to #240.

Activity

  1. changLiuUNSW commented on Dec 1, 2017

    @changLiuUNSW

    Thanks @filipesilva. I will have a test tonight and get back to you ASAP.

  2. changLiuUNSW commented on Dec 1, 2017

    @changLiuUNSW
    $ node -v
    v7.5.0
    
    $ ng -v
    
    Angular CLI: 1.5.5
    Node: 7.5.0
    OS: win32 x64
    Angular: 5.0.4
    ... 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.5
    @angular-devkit/build-optimizer: 0.0.34
    @angular-devkit/core: 0.0.22
    @angular-devkit/schematics: 0.0.38
    @ngtools/json-schema: 1.1.0
    @ngtools/webpack: 1.8.5
    @schematics/angular: 0.1.8
    typescript: 2.4.2
    webpack-bundle-analyzer: 2.9.1
    webpack: 3.8.1
    
    $ ng build --prod
    Time: 280909ms
    chunk {0} polyfills.953b2ea9f096cadfdccc.bundle.js (polyfills) 146 kB [initial] [rendered]
    chunk {1} main.b072d0d00d3efb0bb504.bundle.js (main) 1.78 MB [initial] [rendered]
    chunk {2} styles.d1f7c9f576103c62cb95.bundle.css (styles) 108 kB [initial] [rendered]
    chunk {3} inline.94db4a86d65f89eca9e2.bundle.js (inline) 1.49 kB [entry] [rendered]
    
    $ ng build --prod --build-optimizer=false
    Time: 178722ms
    chunk {0} polyfills.50f5381850b537ae213f.bundle.js (polyfills) 147 kB [initial] [rendered]
    chunk {1} main.c2e1bcb424c7762ae48a.bundle.js (main) 1.34 MB [initial] [rendered]
    chunk {2} styles.d1f7c9f576103c62cb95.bundle.css (styles) 108 kB [initial] [rendered]
    chunk {3} vendor.74317826779ffe91983b.bundle.js (vendor) 650 kB [initial] [rendered]
    chunk {4} inline.3e5e45cce1262d7aea45.bundle.js (inline) 1.5 kB [entry] [rendered]
    

    Only around 2 minutes difference now !Thanks for your hard work @filipesilva.
    If we can make the difference within 1 minute , so much the better :)
    Thanks again.

  3. filipesilva commented on Dec 1, 2017

    @filipesilva
    ContributorAuthor

    All credit goes to @clydin, he's the one working on reducing Build Optimizer run time and memory usage.

  4. cazfletch commented on Dec 14, 2017

    @cazfletch

    Hi i am also having this issue but am not using angular-cli, any recomendations what i can do to make my build work with build-optimizer turned on. In my case it gets to around 50% then hangs forever

  5. filipesilva commented on Dec 18, 2017

    @filipesilva
    ContributorAuthor

    @caroline-church is your project open source or available for me to see somewhere?

  6. cazfletch commented on Dec 18, 2017

    @cazfletch

    @filipesilva here is my branch https://github.com/caroline-church/fabric-composer/tree/improve-performance-2. Its a mono-repo so you have to run npm install in the top level directory. The package you want to look at is composer-playground. If you run npm run buikd:prod you will see the problem. I narrowed it down to that the problem was the composer-common dependency, but wasn't sure why it would cause a problem.

  7. pjmolina commented on Dec 22, 2017

    @pjmolina

    Hi everyone!
    I have a case when building for production an ng app:

    This hangs forever (it is not a memory problem, uses around 400Mb) but keeps consuming CPU and do not finish.
    ng build -e prod -prod -aot --base-href x

    This other one, disabling the build optimizer, works:
    ng build -e prod -prod -aot --base-href x --build-optimizer=false

    One particularity on the ng project is that it contains one big/medium file (a generated parser) of 108 Kb in size and this looks to be the hanging point.

    Versions used:

    Angular CLI: 1.6.2
    Node: 8.6.0
    OS: win32 x64
    Angular: 5.1.2
    @angular/cli: 1.6.2
    @angular-devkit/build-optimizer: 0.0.36
    @angular-devkit/core: 0.0.22
    @angular-devkit/schematics: 0.0.42
    @ngtools/json-schema: 1.1.0
    @ngtools/webpack: 1.9.2
    @schematics/angular: 0.1.11
    typescript: 2.5.3
    webpack: 3.10.0
    

    The project is not open source, cannot share it as is. But I can prepare a private repro sample if requested.

  8. filipesilva commented on Dec 22, 2017

    @filipesilva
    ContributorAuthor

    @pjmolina that's pretty interesting, the big file. Is the file itself something you can share?

  9. pjmolina commented on Dec 22, 2017

    @pjmolina

    @filipesilva Yes, in a private way (not for public disclosure).
    I can sent it to you by e-mail.

  10. pjmolina commented on Dec 22, 2017

    @pjmolina

    @filipesilva I just created a shared full repro sample.

  11. filipesilva commented on Dec 28, 2017

    @filipesilva
    ContributorAuthor

    @pjmolina thanks a bunch for putting that repro up! I'll have a look to see if there's a specific build optimizer optimization that's causing problems.

    /cc @clydin

  12. filipesilva commented on Dec 28, 2017

    @filipesilva
    ContributorAuthor

    I ran some tests disabling each individual optimization that Build Optimizer does and the culprit seems to be https://github.com/angular/devkit/blob/master/packages/angular_devkit/build_optimizer/src/transforms/prefix-classes.ts.

    We're probably doing something horribly inefficient there and it takes a long time on big files.

  13. pjmolina commented on Dec 28, 2017

    @pjmolina

    Just in case, if the TypeScript compiler/lib is involved, as an hypothesis: Could it be related to this other bug: TypeScript #17033 I reported on the TS compiler?

  14. filipesilva commented on Dec 28, 2017

    @filipesilva
    ContributorAuthor

    Unsure... but something odd is happening here. I tried using the node inspector to get a CPU profile, and... it crashes.

    I set a breakpoint right before Build Optimizer starts processing parser.ts and if I take a CPU profile then, for any amount of time (even something like 1s) and stop, the profiler will go up to 15gigs of ram trying to process it and crash chrome.

    I might be related to that TS issue yes. Build Optimizer processes input files as JS files with allowJs. I double checked and it turns out the only applicable transform for the big file is prefix-classes so that's the one that ran. But now I tried forcing another transform for that file instead of prefix-classes and it also hangs.

    So yeah, I think it boils down to microsoft/TypeScript#17033.

  15. clydin commented on Dec 28, 2017

    @clydin
    Member

    Did a quick test with PR #346 and a production build (ng build --prod) finishes in ~18 seconds. The culprit appears to be the type analysis phase of the TS compiler. The massive amount of nesting in the large parser file is probably the issue.

  16. filipesilva commented on Dec 28, 2017

    @filipesilva
    ContributorAuthor

    I think #346 is a great improvement, but worry about the sourcemap limitation. It means there are situations where having sourcemaps in production might mean extremely lengthy build. But that's the case now anyways.

  17. alexeagle commented on Sep 4, 2018

    @alexeagle
    Contributor

    This issue was moved to angular/angular-cli#12153

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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions