Faster AOT build time for dev mode

[robianmcd]

[x ] feature request

Current behavior
Running the AOT compiler-cli for a project with 1 module and 1 component takes around 7 seconds

.\node_modules\.bin\ngc -p .\tsconfig.json

Desired behavior
Build runs faster. e.g. < 1 second.

Minimal reproduction of the problem with instructions
Use the app from the aot compilation cookbook https://angular.io/docs/ts/latest/cookbook/aot-compiler.html

What is the motivation / use case for changing the behavior?
I am trying to make the dev build and prod build for an Angular app as similar as possible to minimize the complexity of the build and minimize error in prod that don't happen in dev. It would really help to simplify the build process if the AOT compiler could run fast enough to be run whenever a TS file is saved so it could be used for dev and prod.

Please tell us about your environment:
OS: Windows 10
Node: 7.2.0
Angular: 2.3.0

[alexeagle]

We added the annotationsAs option to angularCompilerOptions as one way to improve this problem.
See
https://github.com/angular/angular/blob/master/tools/%40angular/tsc-wrapped/src/options.ts#L45

Long term the only way to make ngc (and tsc) fast for incremental compilation of a large application is to split into multiple compilation units.

[robianmcd]

Thanks @alexeagle! That shaved about 2 seconds off the build. It takes about 5 seconds to run ngc now. If I just run tsc it takes 3.5 seconds. So I'm going to go ahead and run AOT in dev and prod as running tsc directly wouldn't save me much time. But 6 seconds (5 for ngc, 1 for rollup) still seems a bit slow to build a hello world app.

[tbosch]

Tracking issue for watch mode is here: #13475

[kylecordes]

I have a somewhat unusual use case... I frequently AOT about 70 small programs. AOT speed is very noticeable. (To make it bearable, I use GNU Parallel to spread that work across cores.)

Speaking of "multiple compilation units", is a possible there is an easy initial win, to cache and reuse the already-AOTed code from Angular itself, rather than re-AOT all that on each build? That is the most obvious low hanging fruit as I watch this process happen, regenerating many of the same files 70 times.

[alexeagle]

@kylecordes we do that internally at google:

• using bazel (the rules are not open-sourced yet)
• we compile Angular once per package with ngc
• we compile user code with ngc using the .ngsummary.json and .d.ts files from Angular
• we have a different ReflectorHost so we don't try to do codegen for any files that are presented as .d.ts rather than .ts

sorry this is probably hard to reproduce right now but we want to open-source the bazel build (so Angular itself can use it). Maybe in a couple quarters...

[kylecordes]

@alexeagle Thank you, I will give it a try based on this info. No Bazel over here, but in the ancient past I used make and other tools that track dependencies by monitoring file access and so on. I suspect I can speed up my 70-program build by reusing some ngc output. Maybe get a blog post out of it.

We are working on a pattern (details still in turmoil) of developing scaled out Angular applications in a Lerna monorepo, with most of the functionality in a set of modules in their own packages, compiled into various combinations in a smaller set of top-level applications that glue things together. With the current state-of-the-art this means lots of little projects doing their own ngc - so even a slightly hacking way of reusing that output could move this approach from impractical to practical.

[alexeagle]

That sounds just like what we are doing. Let me know if you want to compare notes.

…

On Fri, Mar 10, 2017 at 5:14 PM Kyle Cordes ***@***.***> wrote: @alexeagle <https://github.com/alexeagle> Thank you, I will give it a try based on this info. No Bazel over here, but in the ancient past I used make and other tools that track dependencies by monitoring file access and so on. I suspect I can speed up my 70-program build by reusing some ngc output. Maybe get a blog post out of it. We are working on a pattern (details still in turmoil) of developing scaled out Angular applications in a Lerna monorepo, with most of the functionality in a set of modules in their own packages, compiled into various combinations in a smaller set of top-level applications that glue things together. With the current state-of-the-art this means lots of little projects doing their own ngc - so even a slightly hacking way of reusing that output could move this approach from impractical to practical. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13475 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC5I39_N-QpPgbSSjTFtA46EoqlSAOkks5rkfVagaJpZM4LNXvt> .

[pauldraper]

@alexeagle is ngsummary documented anywhere?

Thanks for the info. Considering that Angular and Bazel are both open-source projects, hopefully open-sourcing Angular Bazel rules won't be too hard :)

[kylecordes]

Update... I took a swing at this a couple weeks ago but ended up setting it aside for the moment. The tricky part is not the ngsummary documentation (treat those files is a black box for this) nor even necessarily the build tooling. But rather that as @alexeagle wrote, you need a modified ReflectorHost - a class deep inside Angular. Which means that anything built with this approach necessarily is running off of a fork or monkey patch of Angular. That would limit our ability to make practical use of such an improvement in our "real work" here (our customers have limited interest in running a fork of Angular...).

I think the most useful thing that could come out of the core project to enable the use on the outside, would be to ship the necessary alternate ReflectorHost behavior in the open source box. Not so much for the code itself, but because by doing so presumably it would land in the official Angular bundles activated by a config switch to ngc or similar.

[alexeagle]

FWIW, our bazel implementation of the ReflectorHost is just 100 lines of simple implementations of each CompilerHost method.
We'll open-source it as part of the ABC effort, which will also ship the fast builds of multiple-compilation-units.

[geoff-mci]

@tbosch I think the tracking issue is #12867

[pkozlowski-opensource]

With Angular v9 + ivy AoT builds should be significantly faster so going to close this one. If anyone is facing specific slow-down please open a new issue with a minimal reproduce scenario.

[angular-automatic-lock-bot]

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