perf(ngcc): performance improvements #38840

JoostK · 2020-09-14T12:24:06Z

See individual commits.

Recent optimizations to ngcc have significantly reduced the total time it takes to process `node_modules`, to such extend that sharding across multiple processes has become less effective. Previously, running ngcc asynchronously would allow for up to 8 workers to be allocated, however these workers have to repeat work that could otherwise be shared. Because ngcc is now able to reuse more shared computations, the overhead of multiple workers is increased and therefore becomes less effective. As an additional benefit, having fewer workers requires less memory and less startup time. To give an idea, using the following test setup: ```bash npx @angular/cli new perf-test cd perf-test yarn ng add @angular/material ./node_modules/.bin/ngcc --properties es2015 module main \ --first-only --create-ivy-entry-points ``` We observe the following figures on CI: | | 10.1.1 | PR angular#38840 | | ----------------- | --------- | --------- | | Sync | 85s | 25s | | Async (8 workers) | 22s | 16s | | Async (4 workers) | - | 11s |

JoostK · 2020-09-14T15:56:31Z

I ran this on ngcc-validation on a 8-core/16-thread CPU:

Using 4 workers:

time ./node_modules/.bin/ngcc --create-ivy-entry-points --error-on-failed-entry-point --first-only --properties es2015 browser module main --no-tsconfig
315.90s user / 29.88s system / 454% cpu / 1:16.06 total

Using 8 workers:

time ./node_modules/.bin/ngcc --create-ivy-entry-points --error-on-failed-entry-point --first-only --properties es2015 browser module main --no-tsconfig
423.24s user / 41.97s system / 830% cpu / 56.000 total

Here, the 8 worker scenario is slightly faster, which is somewhat expected for ngcc-validation as it has lots of independent packages, so it is able to feed all workers with work very effectively. The situation with 4 workers is still significantly faster than master currently is using 8 workers:

time ./node_modules/.bin/ngcc --create-ivy-entry-points --error-on-failed-entry-point --first-only --properties es2015 browser module main --no-tsconfig
1083.92s user / 107.51s system / 913% cpu / 2:10.39 total

Additionally, quad-core CPUs with hyper-threading report 8 available CPUs, so we'd completely drown the CPU in 7 ngcc workers. I expect only 4 workers to be typically faster even, as is the case in a smaller setup with just @angular/material (see commit message of b5a8a50), so I think that reducing the number of workers to a maximum of 4 is the right balance.

EDIT:

With the addition of @angular package caching, the figures have improved a bit more:

time ./node_modules/.bin/ngcc --create-ivy-entry-points --error-on-failed-entry-point --first-only --properties es2015 browser module main --no-tsconfig
255.97s user / 27.28s system / 535% cpu / 52.852 total

packages/compiler-cli/ngcc/src/execution/create_compile_function.ts

packages/compiler-cli/ngcc/src/packages/transform_cache.ts

Recent optimizations to ngcc have significantly reduced the total time it takes to process `node_modules`, to such extend that sharding across multiple processes has become less effective. Previously, running ngcc asynchronously would allow for up to 8 workers to be allocated, however these workers have to repeat work that could otherwise be shared. Because ngcc is now able to reuse more shared computations, the overhead of multiple workers is increased and therefore becomes less effective. As an additional benefit, having fewer workers requires less memory and less startup time. To give an idea, using the following test setup: ```bash npx @angular/cli new perf-test cd perf-test yarn ng add @angular/material ./node_modules/.bin/ngcc --properties es2015 module main \ --first-only --create-ivy-entry-points ``` We observe the following figures on CI: | | 10.1.1 | PR angular#38840 | | ----------------- | --------- | --------- | | Sync | 85s | 25s | | Async (8 workers) | 22s | 16s | | Async (4 workers) | - | 11s |

JoostK · 2020-09-14T20:12:01Z

Here's the figures for a bare CLI app with @angular/material added, such that there is a somewhat representative number of entry-points to process:

npx @angular/cli new ngcc-perf
cd ngcc-perf
yarn ng add @angular/material

On master, sync:

time ./node_modules/.bin/ngcc --properties es2015 module main --first-only --create-ivy-entry-points --no-async
101.68s user / 6.31s system / 155% cpu / 1:09.60 total

This PR, sync:

time ./node_modules/.bin/ngcc --properties es2015 module main --first-only --create-ivy-entry-points --no-async
24.48s user / 1.58s system / 164% cpu / 15.845 total

On master, async (8 workers):

time ./node_modules/.bin/ngcc --properties es2015 module main --first-only --create-ivy-entry-points
170.34s user / 12.49s system / 888% cpu / 20.581 total

This PR, async (4 workers):

time ./node_modules/.bin/ngcc --properties es2015 module main --first-only --create-ivy-entry-points
40.32s user / 3.23s system / 463% cpu / 9.407 total

petebacondarwin

Nice work @JoostK - I don't see any issues with the logic.

Regarding structure, I would extract the module resolution cache from the TransformCache unless I am missing something.

Regarding naming, I would consider SharedFileCache and EntryPointFileCache - which only work if they are not responsible for the module resolution cache.

packages/compiler-cli/ngcc/src/packages/transform_cache.ts

packages/compiler-cli/ngcc/src/main.ts

petebacondarwin · 2020-09-15T08:34:32Z

Oh one more thing regarding the synchronous CLI integration. What about adding the TransformCache to the API that the CLI uses to invoke ngcc. This would allow the CLI to be able to provide a cache where it can control invalidating files, since it would be able to know about that. Then we could share these cached files between synchronous invocations of ngcc in the CLI.

JoostK · 2020-09-15T08:43:04Z

Oh one more thing regarding the synchronous CLI integration. What about adding the TransformCache to the API that the CLI uses to invoke ngcc. This would allow the CLI to be able to provide a cache where it can control invalidating files, since it would be able to know about that. Then we could share these cached files between synchronous invocations of ngcc in the CLI.

I would rather not at this point. The configuration is already complex and allowing for external invalidation of caches introduces yet more public API and the possibility for bugs of stale caches. The changes in this PR are purely internal, which gives us infinite freedom in what we deem safe to cache and for how long.

Recent optimizations to ngcc have significantly reduced the total time it takes to process `node_modules`, to such extend that sharding across multiple processes has become less effective. Previously, running ngcc asynchronously would allow for up to 8 workers to be allocated, however these workers have to repeat work that could otherwise be shared. Because ngcc is now able to reuse more shared computations, the overhead of multiple workers is increased and therefore becomes less effective. As an additional benefit, having fewer workers requires less memory and less startup time. To give an idea, using the following test setup: ```bash npx @angular/cli new perf-test cd perf-test yarn ng add @angular/material ./node_modules/.bin/ngcc --properties es2015 module main \ --first-only --create-ivy-entry-points ``` We observe the following figures on CI: | | 10.1.1 | PR angular#38840 | | ----------------- | --------- | --------- | | Sync | 85s | 25s | | Async (8 workers) | 22s | 16s | | Async (4 workers) | - | 11s |

petebacondarwin

LGTM

d3lm · 2020-09-15T13:41:27Z

Very cool! Nice job @JoostK 👍 Love this ❤️

👏 👏 👏

Recent optimizations to ngcc have significantly reduced the total time it takes to process `node_modules`, to such extend that sharding across multiple processes has become less effective. Previously, running ngcc asynchronously would allow for up to 8 workers to be allocated, however these workers have to repeat work that could otherwise be shared. Because ngcc is now able to reuse more shared computations, the overhead of multiple workers is increased and therefore becomes less effective. As an additional benefit, having fewer workers requires less memory and less startup time. To give an idea, using the following test setup: ```bash npx @angular/cli new perf-test cd perf-test yarn ng add @angular/material ./node_modules/.bin/ngcc --properties es2015 module main \ --first-only --create-ivy-entry-points ``` We observe the following figures on CI: | | 10.1.1 | PR angular#38840 | | ----------------- | --------- | --------- | | Sync | 85s | 25s | | Async (8 workers) | 22s | 16s | | Async (4 workers) | - | 11s | In addition to changing the default number of workers, ngcc will now use the environment variable `NGCC_MAX_WORKERS` that may be configured to either reduce or increase the number of workers.

gkalpak

Fantastic work! 💯 🚀 👨‍🎤

packages/compiler-cli/ngcc/src/packages/source_file_cache.ts

gkalpak · 2020-09-15T16:20:34Z

packages/compiler-cli/ngcc/src/ngcc_options.ts

+  const maxWorkers = process.env.NGCC_MAX_WORKERS;
+  if (maxWorkers === undefined) {
+    // Use up to 4 CPU cores for workers, always reserving one for master.
+    return Math.max(1, Math.min(4, os.cpus().length - 1));


Nit: FWIW, I would find it more intuitive to return 0 when there are not enough CPUs for workers (i.e. when os.cpus().length < 2).

That's an interesting point, especially when considering how to configure NGCC_MAX_WORKERS. Currently I require that to be at least 1, but that doesn't mean that it'll actually spawn a single worker, as it's smart enough to run it in the same process. So from that perspective, returning 0 here if there's too few CPUs feels inconsistent to me (without also changing how we interpret NGCC_MAX_WORKERS). I feel it would be quite awkward to allow NGCC_MAX_WORKERS=0 which would operate identically to NGCC_MAX_WORKERS=1.

I don't necessarily agree, but I don't feel strongly about this at all (so it works for me as is) 😅

ngcc creates typically two `ts.Program` instances for each entry-point, one for processing sources and another one for processing the typings. The creation of these programs is somewhat expensive, as it concerns module resolution and parsing of source files. This commit implements several layers of caching to optimize the creation of programs: 1. A shared module resolution cache across all entry-points within a single invocation of ngcc. Both the sources and typings program benefit from this cache. 2. Sharing the parsed `ts.SourceFile` for a single entry-point between the sources and typings program. 3. Sharing parsed `ts.SourceFile`s of TypeScript's default libraries across all entry-points within a single invocation. Some of these default library typings are large and therefore expensive to parse, so sharing the parsed source files across all entry-points offers a significant performance improvement. Using a bare CLI app created using `ng new` + `ng add @angular/material`, the above changes offer a 3-4x improvement in ngcc's processing time when running synchronously and ~2x improvement for asynchronous runs.

Recent optimizations to ngcc have significantly reduced the total time it takes to process `node_modules`, to such extend that sharding across multiple processes has become less effective. Previously, running ngcc asynchronously would allow for up to 8 workers to be allocated, however these workers have to repeat work that could otherwise be shared. Because ngcc is now able to reuse more shared computations, the overhead of multiple workers is increased and therefore becomes less effective. As an additional benefit, having fewer workers requires less memory and less startup time. To give an idea, using the following test setup: ```bash npx @angular/cli new perf-test cd perf-test yarn ng add @angular/material ./node_modules/.bin/ngcc --properties es2015 module main \ --first-only --create-ivy-entry-points ``` We observe the following figures on CI: | | 10.1.1 | PR angular#38840 | | ----------------- | --------- | --------- | | Sync | 85s | 25s | | Async (8 workers) | 22s | 16s | | Async (4 workers) | - | 11s | In addition to changing the default number of workers, ngcc will now use the environment variable `NGCC_MAX_WORKERS` that may be configured to either reduce or increase the number of workers.

In the integration test suite of ngcc, we load a set of files from `node_modules` into memory. This includes the `typescript` package and `@angular` scoped packages, which account for a large number of large files that needs to be loaded from disk. This commit moves this work to the top-level, such that it doesn't have to be repeated in all tests.

) ngcc creates typically two `ts.Program` instances for each entry-point, one for processing sources and another one for processing the typings. The creation of these programs is somewhat expensive, as it concerns module resolution and parsing of source files. This commit implements several layers of caching to optimize the creation of programs: 1. A shared module resolution cache across all entry-points within a single invocation of ngcc. Both the sources and typings program benefit from this cache. 2. Sharing the parsed `ts.SourceFile` for a single entry-point between the sources and typings program. 3. Sharing parsed `ts.SourceFile`s of TypeScript's default libraries across all entry-points within a single invocation. Some of these default library typings are large and therefore expensive to parse, so sharing the parsed source files across all entry-points offers a significant performance improvement. Using a bare CLI app created using `ng new` + `ng add @angular/material`, the above changes offer a 3-4x improvement in ngcc's processing time when running synchronously and ~2x improvement for asynchronous runs. PR Close #38840

Recent optimizations to ngcc have significantly reduced the total time it takes to process `node_modules`, to such extend that sharding across multiple processes has become less effective. Previously, running ngcc asynchronously would allow for up to 8 workers to be allocated, however these workers have to repeat work that could otherwise be shared. Because ngcc is now able to reuse more shared computations, the overhead of multiple workers is increased and therefore becomes less effective. As an additional benefit, having fewer workers requires less memory and less startup time. To give an idea, using the following test setup: ```bash npx @angular/cli new perf-test cd perf-test yarn ng add @angular/material ./node_modules/.bin/ngcc --properties es2015 module main \ --first-only --create-ivy-entry-points ``` We observe the following figures on CI: | | 10.1.1 | PR #38840 | | ----------------- | --------- | --------- | | Sync | 85s | 25s | | Async (8 workers) | 22s | 16s | | Async (4 workers) | - | 11s | In addition to changing the default number of workers, ngcc will now use the environment variable `NGCC_MAX_WORKERS` that may be configured to either reduce or increase the number of workers. PR Close #38840

In the integration test suite of ngcc, we load a set of files from `node_modules` into memory. This includes the `typescript` package and `@angular` scoped packages, which account for a large number of large files that needs to be loaded from disk. This commit moves this work to the top-level, such that it doesn't have to be repeated in all tests. PR Close #38840

Recent optimizations to ngcc have significantly reduced the total time it takes to process `node_modules`, to such extend that sharding across multiple processes has become less effective. Previously, running ngcc asynchronously would allow for up to 8 workers to be allocated, however these workers have to repeat work that could otherwise be shared. Because ngcc is now able to reuse more shared computations, the overhead of multiple workers is increased and therefore becomes less effective. As an additional benefit, having fewer workers requires less memory and less startup time. To give an idea, using the following test setup: ```bash npx @angular/cli new perf-test cd perf-test yarn ng add @angular/material ./node_modules/.bin/ngcc --properties es2015 module main \ --first-only --create-ivy-entry-points ``` We observe the following figures on CI: | | 10.1.1 | PR #38840 | | ----------------- | --------- | --------- | | Sync | 85s | 25s | | Async (8 workers) | 22s | 16s | | Async (4 workers) | - | 11s | In addition to changing the default number of workers, ngcc will now use the environment variable `NGCC_MAX_WORKERS` that may be configured to either reduce or increase the number of workers. PR Close #38840

In the integration test suite of ngcc, we load a set of files from `node_modules` into memory. This includes the `typescript` package and `@angular` scoped packages, which account for a large number of large files that needs to be loaded from disk. This commit moves this work to the top-level, such that it doesn't have to be repeated in all tests. PR Close #38840

angular-automatic-lock-bot · 2020-10-16T16:27:56Z

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

JoostK added type: bug/fix area: performance state: WIP target: patch This PR is targeted for the next patch release comp: ngcc labels Sep 14, 2020

ngbot bot added this to the needsTriage milestone Sep 14, 2020

googlebot added the cla: yes label Sep 14, 2020

JoostK force-pushed the ngcc/perf branch from d268dc7 to 925e4f4 Compare September 14, 2020 14:13

JoostK force-pushed the ngcc/perf branch from 925e4f4 to 1b5592e Compare September 14, 2020 15:00

JoostK added action: review The PR is still awaiting reviews from at least one requested reviewer and removed state: WIP labels Sep 14, 2020

JoostK marked this pull request as ready for review September 14, 2020 15:25

JoostK added a commit to JoostK/ngcc-validation that referenced this pull request Sep 14, 2020

build: test angular/angular#38840

b526e33

JoostK commented Sep 14, 2020

View reviewed changes

packages/compiler-cli/ngcc/src/execution/create_compile_function.ts Outdated Show resolved Hide resolved

JoostK commented Sep 14, 2020

View reviewed changes

packages/compiler-cli/ngcc/src/packages/transform_cache.ts Outdated Show resolved Hide resolved

JoostK force-pushed the ngcc/perf branch from 1b5592e to 505e729 Compare September 14, 2020 17:50

JoostK force-pushed the ngcc/perf branch from 505e729 to 27a2a25 Compare September 14, 2020 19:58

petebacondarwin requested changes Sep 15, 2020

View reviewed changes

JoostK force-pushed the ngcc/perf branch from 27a2a25 to da5128c Compare September 15, 2020 12:24

petebacondarwin approved these changes Sep 15, 2020

View reviewed changes

JoostK force-pushed the ngcc/perf branch from da5128c to 8791018 Compare September 15, 2020 15:03

gkalpak approved these changes Sep 15, 2020

View reviewed changes

gkalpak added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Sep 15, 2020

JoostK added 8 commits September 15, 2020 18:39

fixup! perf(ngcc): introduce cache for sharing data across entry-points

3921763

fixup! perf(ngcc): introduce cache for sharing data across entry-points

caacb88

fixup! perf(ngcc): introduce cache for sharing data across entry-points

d96393a

fixup! perf(ngcc): introduce cache for sharing data across entry-points

8e91377

fixup! perf(ngcc): reduce maximum worker count

a90270a

JoostK force-pushed the ngcc/perf branch from 8791018 to 8bf1128 Compare September 15, 2020 16:40

JoostK added action: merge The PR is ready for merge by the caretaker and removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews labels Sep 15, 2020

AndrewKushnir closed this in f0688b4 Sep 15, 2020

alan-agius4 mentioned this pull request Sep 23, 2020

Angular 10 taking so long to build angular/angular-cli#18854

Closed

15 tasks

angular-automatic-lock-bot bot locked and limited conversation to collaborators Oct 16, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

perf(ngcc): performance improvements #38840

perf(ngcc): performance improvements #38840

JoostK commented Sep 14, 2020

JoostK commented Sep 14, 2020 •

edited

JoostK commented Sep 14, 2020 •

edited

petebacondarwin left a comment

petebacondarwin commented Sep 15, 2020

JoostK commented Sep 15, 2020

petebacondarwin left a comment

d3lm commented Sep 15, 2020

gkalpak left a comment

gkalpak Sep 15, 2020

JoostK Sep 15, 2020 •

edited

gkalpak Sep 15, 2020

angular-automatic-lock-bot bot commented Oct 16, 2020

perf(ngcc): performance improvements #38840

perf(ngcc): performance improvements #38840

Conversation

JoostK commented Sep 14, 2020

JoostK commented Sep 14, 2020 • edited

JoostK commented Sep 14, 2020 • edited

petebacondarwin left a comment

Choose a reason for hiding this comment

petebacondarwin commented Sep 15, 2020

JoostK commented Sep 15, 2020

petebacondarwin left a comment

Choose a reason for hiding this comment

d3lm commented Sep 15, 2020

gkalpak left a comment

Choose a reason for hiding this comment

gkalpak Sep 15, 2020

Choose a reason for hiding this comment

JoostK Sep 15, 2020 • edited

Choose a reason for hiding this comment

gkalpak Sep 15, 2020

Choose a reason for hiding this comment

angular-automatic-lock-bot bot commented Oct 16, 2020

JoostK commented Sep 14, 2020 •

edited

JoostK commented Sep 14, 2020 •

edited

JoostK Sep 15, 2020 •

edited