Compile time is painfully slow

[jpike88]

Command

build, serve

Description

The ng build/serve compilation times of angular dwarf any other bundler/framework I know of and this is a real drag on my team's development time.

I am wondering if there is perhaps a way to just disable type checking or other things that may be large contributing factors to build time, or some sort of alternative being explored?

Can you also explain a little bit about what % the bottlenecks are right now? It would be good to understand things a little better.

Describe the solution you'd like

A way faster compilation time

Describe alternatives you've considered

There aren't any, because since the linker change in Angular 13, I can't use a 3rd party bundler anymore.

[JoostK]

There aren't any, because since the linker change in Angular 13, I can't use a 3rd party bundler anymore.

You certainly could! The linker is just a Babel plugin that can be incorporated into any build pipeline.

[alan-agius4]

The ng build/serve compilation times of angular dwarf any other bundler/framework I know of and this is a real drag on my team's development time.

What are your build times? Did you try using the experimental esbuild based builder?

I am wondering if there is perhaps a way to just disable type checking or other things that may be large contributing factors to build time, or some sort of alternative being explored?

Have you profiled the build to verify the type-checking is the culprit here?

[jpike88]

Build times are about 30 seconds on first build. Esbuild doesn't seem to make much of a difference.

I've profiled my build running node --cpu-prof node_modules/.bin/ng build, here it is:

profile.zip

It's hard to interpret exactly why it's slow, all I know is that it's slow. And It's not a simple stack to interpret, I have no idea how to answer your question even with the profiles.

[JoostK]

Those are profiles from a production build, right?

[jpike88]

nope, development. our default build is our development build

[jpike88]

or do you mean a production build of angular-cli? If so then yes, v15.1.5

[JoostK]

Those profiles indicate that you have optimizations enabled, as it contains traces of Terser:

Development builds are not expected to have optimizations enabled, as this is known to be expensive. Could you check your build configuration?

[jpike88]

whoops! our ng build and ng serve are configured a little differently for their defaults, I forgot. Here is it properly optimizaed for development, which is closer to the actual speed of build on an M1 Mac (~18 seconds):

Config:

{
							"assets": [
								{
									"glob": "**/*",
									"input": "src/assets/",
									"output": "/"
								},
								{
									"glob": "**/*",
									"input": "node_modules/ngx-extended-pdf-viewer/assets/",
									"output": "/assets/"
								}
							],
							"optimization": false,
							"outputHashing": "none",
							"sourceMap": {
								"scripts": true,
								"styles": true,
								"vendor": false,
								"hidden": false
							},
							"namedChunks": false,
							"aot": true,
							"extractLicenses": false,
							"statsJson": false,
							"progress": true,
							"vendorChunk": true,
							"buildOptimizer": false
						}

attached result
CPU.20230330.183927.62264.0.001.cpuprofile.zip

So not 30 seconds, about 18.

This to me is still uncomfortably slow, both on boot up and waiting from 4 up to another 15 seconds each update is punishing. where is the bottleneck to you in the latest cpuprofile I have?

[JoostK]

Do you have profiles of incremental compilations, not the initial one after startup?

The first and second build are known to be more expensive; only after the second rebuild can incremental type-checking be used due to some technicalities with how template type-checking works. So I'm interested in profiles of rebuilds after the second one, ideally with a no-op change (e.g. introducing a console.log)

[jpike88]

Is there any intent or initiative to improve the speed of the first two builds? I do them often enough that it’s far from ideal. Esbuild had a small but insubstantial effect, is there intent to optimise further?

[JoostK]

Not that I'm aware of at the moment. There's ideas like angular/angular#43131 and angular/angular#43165 that are relevant here.

[jpike88]

It would be good for this to be higher on the list of priorities. So much value is lost in waiting during those precious seconds, it breaks flow.

[jpike88]

@JoostK thanks for your patience, I've dug a little deeper and will give more information now.

It's clear that the esbuilder produces a much faster output and it's the way forward. Unfortunately, while 24 seconds is much faster than 64, two problems exist with esbuild:

• it's not much use as it doesn't handle ng serve, why? is it incremental build related? looks like esbuild is ready to proceed with this being merged Version 0.17.0: rewrite the incremental build apis evanw/esbuild#2816.
• Alternatively, can this be used to boost the existing ng serve implementation? https://github.com/esbuild-kit/esbuild-loader? Seems like it's possible to hook up manually (https://how-to.dev/how-to-speed-up-angular-cli-app-with-esbuild-loader) but not a fun exercise to do.
• 24 seconds is still way too long for what esbuild is capable of. We have a very large (200+ files) server project which builds in 0.3 seconds, it's so fast I barely notice it build when I fire it up each time. our angular project is about 300-400 files (I know templating adds complexity but still). What remaining bottlenecks/phases are there standing in the way?

without esbuild enabled: CPU.20230331.113255.80503.0.001.cpuprofile.zip - 64 seconds

with esbuild enabled CPU.20230331.114951.81858.0.001.cpuprofile.zip - 24 seconds

@clydin as you were working on adding esbuild, may you have some insight here?

[JoostK]

Support for ng serve is being implemented in #24923; esbuild support is not yet feature complete.

The esbuild profile is as expected to me. The main difference in why the CLI with esbuild isn't nearly as fast as bare esbuild is that the TypeScript compiler is still used to parse + type-check + emit modules, given that the AOT compiler is built on top of TypeScript. esbuild is only used for bundling/optimization purposes.

[jpike88]

Oh that’s great timing, didn’t see it. I’m glad that it looks like it’s getting attention anyway.

its the only thing about Angular Im not a fan of, I’ve been using it since the v1 days and love where it’s heading… thanks for your time

[jpike88]

closing and tracking #24923

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