You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 4, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 4, 2025. It is now read-only.
Build Optimizer increasing build time excessively #305
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.
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
@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.
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.
@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.
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?
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.
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.
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.
Activity
changLiuUNSW commentedon Dec 1, 2017
Thanks @filipesilva. I will have a test tonight and get back to you ASAP.
changLiuUNSW commentedon Dec 1, 2017
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.
filipesilva commentedon Dec 1, 2017
All credit goes to @clydin, he's the one working on reducing Build Optimizer run time and memory usage.
cazfletch commentedon Dec 14, 2017
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
filipesilva commentedon Dec 18, 2017
@caroline-church is your project open source or available for me to see somewhere?
cazfletch commentedon Dec 18, 2017
@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:prodyou 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.pjmolina commentedon Dec 22, 2017
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 xThis other one, disabling the build optimizer, works:
ng build -e prod -prod -aot --base-href x --build-optimizer=falseOne 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:
The project is not open source, cannot share it as is. But I can prepare a private repro sample if requested.
filipesilva commentedon Dec 22, 2017
@pjmolina that's pretty interesting, the big file. Is the file itself something you can share?
pjmolina commentedon Dec 22, 2017
@filipesilva Yes, in a private way (not for public disclosure).
I can sent it to you by e-mail.
pjmolina commentedon Dec 22, 2017
@filipesilva I just created a shared full repro sample.
filipesilva commentedon Dec 28, 2017
@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
filipesilva commentedon Dec 28, 2017
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.
pjmolina commentedon Dec 28, 2017
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?
filipesilva commentedon Dec 28, 2017
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.tsand 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 isprefix-classesso that's the one that ran. But now I tried forcing another transform for that file instead ofprefix-classesand it also hangs.So yeah, I think it boils down to microsoft/TypeScript#17033.
clydin commentedon Dec 28, 2017
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.filipesilva commentedon Dec 28, 2017
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.
alexeagle commentedon Sep 4, 2018
This issue was moved to angular/angular-cli#12153