NGC rebuild performance improvements (Ivy & AoT)

🚀 feature request

Relevant Package

This feature request is for @angular/compiler-cli

Description

Thanks to the team my issue https://github.com/angular/angular/issues/33986 was fixed in 9rc4 build. I open this feature request to ask (prioritize) others impovements regarding ngc rebuild, actually in large project 8-15s rebuild (on each file change) is pretty long.

Repro

I think I succeed to repro a rebuild slowness by multiply by 2 the number of components (now 817) in my last issue repro ng-speed-rebuild Clone master branch, create ngcc ivy entry points, run npm run ngc to start the project. Here’s ngc-9rc9.cpuprofile of an isolated rebuild of the repro.

Describe the solution you’d like

Out of scope to me. From what I’ve learned/heard the long phase is: emitting and reparse all components on each rebuild

Describe alternatives you’ve considered

1. I tried on two differents hardware (VM ubuntu & win10) rebuild time is pretty same.
2. I can’t be sure if ng-speed-rebuild repro is reflecting our private project because we have a lot of imports/exports/shared components. On our private project we have 850 components, if it can help here you are a .cpuprofile of an isolated ngc rebuild of our private project private-project-ngc-9rc9.cpuprofile
3. NOTE: With CLI 9rc9 ng serve rebuild is weird and really longer https://github.com/elvisbegovic/ng-speed-rebuild#ng-serve-9rc9-rebuild--83s---7s---5s---15s---17s---14s

Other

Might be related to https://github.com/angular/angular/issues/34796 (wait repro)

[alxhub]

@elvisbegovic thank you so much for the reproduction! These kinds of examples are invaluable in diagnosing performance issues. I’ve already found a couple interesting issues from this repo:

1. The way we implement template type-checking triggers “safe modules” reuse in TypeScript, which is slower than “complete” program reuse. I have an idea for how to avoid this, which I’ll play around with.

2. In this repo, during incremental build steps TypeScript does reports that a number of .d.ts files have changed between builds (obviously this isn’t the case). This causes us to deopt and not reuse any parts of Angular analysis or previous emit results. It’s a huge performance hit and is only marginally faster than a full fresh build. Ouch.

3. The dependency graph seems to require the re-emit of all the components when the one you suggested is changed anyway. This seems excessive, and I need to dig into why the graph is shaped as such. Perhaps there’s room for improvement here.

I’ll dig into these. Thanks!

[elvisbegovic]

Hey guys, this seems cool.

Click here to see stats/diff between Angular 11.2.1 VS 11.2.6 on Google Sheet NGC profiles Click here to download isolated .cpuprofile of a rebuild on Angular 11.2.1 Click here to download isolated .cpuprofile of a rebuild on Angular 11.2.6 NG SERVE profiles .cpuprofile of a rebuild on ng serve11.2.5 NO sourcemap .cpuprofile of a rebuild on ng serve11.2.5 WITH sourcemap{scripts,styles}

cc/ @JoostK