Angular-cli: Compile times hit 30 seconds or higher for simple changes when using ng serve

[chrillewoodz]

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

angular-cli: 1.0.0
node: 6.9.2
os: darwin x64
@angular/animations: 4.0.0
@angular/common: 4.0.0
@angular/compiler: 4.0.0
@angular/core: 4.0.0
@angular/forms: 4.0.0
@angular/http: 4.0.0
@angular/platform-browser: 4.0.0
@angular/platform-browser-dynamic: 4.0.0
@angular/router: 4.0.0
@angular/cli: 1.0.0
@angular/compiler-cli: 4.0.0

Repro steps.

I've not been able to pinpoint this exactly but it seems as if the issue comes whenever changing things in the shared folder.

My folder structure looks like this (starting in /app):

- routes
- shared
  - animations
  - components
  - directives
  - constants
  - interfaces
  - guards
  - services
  - validators
  - pipes
  - modules
    - components.module.ts // Imports and exports all components in the components folder
    - shared.module.ts // Imports and exports all pipes and directives as well as the necessary angular modules that each page module will need in order to work

When changes things in the routes folder the compile does not take as long, but it can still be between 5-15 seconds. When changing something in the components folder for example, I need to sit and wait for at least 20 seconds, even for small changes such as changing a number from a 0 to a 1. Which is just ridiculous.

Desired functionality.

I'm expecting compile times to not be above 10 seconds, regardless of the size of the change.

Mention any other details that might be useful.

I didn't notice this change in the 1.0.0-beta.26 version which I was using earlier with the exact same structure. This began when I switched over to angular 4 and the non-beta version of the CLI (1.0.0). I can't provide a repo unfortunately since the code is not open source, but hopefully this is enough in order to investigate.

Each folder in the shared folder can have quite a lot of files in them. components and interfaces are especially large since they can have nested folders about 3-4 levels deep. Right now the components folder have about 20 components in it and the more I add the more it seems to slow down.

If you require further information just ask, I would really love for this one to get solved as quickly as possible.

[intellix]

I feel like I've got a fairly large app and compile times are more like 400ms - 1s when saving throughout. I've just counted the files in a variety of folders and I get these numbers:

find src -type f | wc -l               # 736
find src/app -type f | wc -l           # 475
find src/app/shared -type f | wc -l    # 157

I see you're on OSX, but you're not using something like Docker right? which has I/O performance issues on OSX

Edit: Forgot to include my system setup :)

@angular/cli: 1.0.0
node: 7.1.0
os: darwin x64
@angular/animations: 4.1.0
@angular/cli: 1.0.0
@angular/common: 4.1.0
@angular/compiler: 4.1.0
@angular/compiler-cli: 4.1.0
@angular/core: 4.1.0
@angular/flex-layout: 2.0.0-beta.8
@angular/forms: 4.1.0
@angular/http: 4.1.0
@angular/platform-browser: 4.1.0
@angular/platform-browser-dynamic: 4.1.0
@angular/router: 4.1.0

[chrillewoodz]

@intellix Yours is about twice the size of mine then. I get these results:

380
342
189

No I'm not using Docker or anything special. Just a cli install. Also I'm using the local version instead of the global one, but I'm not sure that could have any affect, it really shouldn't.

[clydin]

Something to look at is the dependency hierarchy of the application. If every Angular module of the application is importing the components and shared modules, than any change in one of those will essentially cause the entire application to be rebuilt.
The use of more granular modules within the shared aspects of the application or even using direct imports of a shared pipe or service (where appropriate) should help limit the scope of a rebuild.

[hansl]

@intellix I feel like this could be a regression. Did you try upgrading to 1.0.6? It should be straightforward; ie. just npm install.

[orax-pkrupicka]

I have the same problem. When I used Angular 2.3.4 the compilation took 10 - 14 seconds. After upgrading to Angular 4.1.3, the compilation of the same project takes 18-26 seconds. It's unpleasant.

[orax-pkrupicka]

I was looking for where could be a problem. I have upgraded the npm module typescript from version 2.0.10 to 2.3.4 and the compile time has returned to the original values (9 - 12s).

[intellix]

Just updated @hansl and tried some rebuilds. Didn't see any regression and it felt a bit quicker actually. 500ms -> 1.3s rebuilds, no matter where I did them either

@angular/cli: 1.0.6
node: 7.9.0
os: darwin x64
@angular/animations: 4.1.3
@angular/cli: 1.0.6
@angular/common: 4.1.3
@angular/compiler: 4.1.3
@angular/compiler-cli: 4.1.3
@angular/core: 4.1.3
@angular/flex-layout: 2.0.0-beta.8
@angular/forms: 4.1.3
@angular/http: 4.1.3
@angular/platform-browser: 4.1.3
@angular/platform-browser-dynamic: 4.1.3
@angular/router: 4.1.3
@angular/service-worker: 1.0.0-beta.5

[ivanovjaroslaw]

Can it be "ts-node"?
I am from "mgechev/angular-seed" and we also have problems with rebuild (30-50 seconds). And as I see "ts-node" is intersection between us.
We got it after upgrading angular from 2 to 4 and typescript from 2.0 to 2.3.

Also now tried to update "node" (from 6.9.5 to 7.9.0 as @intellix said), but nothing.

Moreover, I see that every new rebuild increases the time:
1) First rebuild after 'start' (just changing some comment in *.ts file): 35s
2) 48s
3) 1.05m
4) 1.32m
...

[GoNode5]

@intellix could you share what kind of hardware?

[intellix]

@GoNode5
Macbook Pro (Retina, 13-inch, Early 2015)
Processor: 2.7 GHz Intel Core i5
Memory: 8GB 1867MHz DDR3

[chrillewoodz]

I just got a new MacBook Pro today with 516GB SSD and like all the best you can get, and I still get mad compile times. So the hardware shouldn't the be culprit in this case. I also tried upgrading typescript to 2.3.4 as suggested by @orax-pkrupicka but I still can't notice any difference.

[ivanovjaroslaw]

Some updates about it?

[crain]

I am having serious performance issues as well. The most time its stuck at "92 % chunk asset optimization"

ng serve --verbose

33956ms building modules
163ms sealing
14ms optimizing
0ms basic module optimization
0ms module optimization
110ms advanced module optimization
351ms basic chunk optimization
1ms chunk optimization
0ms advanced chunk optimization
5ms module and chunk tree optimization
1ms module reviving
74ms module order optimization
37ms module id optimization
2ms chunk reviving
9ms chunk order optimization
32ms chunk id optimization
943ms hashing
2ms module assets processing
1197ms chunk assets processing
8ms additional chunk assets processing
1ms recording
1ms additional asset processing
184448ms chunk asset optimization
25ms asset optimization
1036ms emitting
Hash: a76203296dcfdeb3e4d8
Version: webpack 2.4.1
Time: 222443ms

@angular/cli: 1.1.2
Windows 10 Pro, Version 1703, Build: 15063.413
Hardware: Intel Core i7-6560U CPU, 2.21 GHZ, 16 GB RAM

I am having about 13 feature modules in my project.

Is there a way to see what's going on in step chunk asset optimization?

[moneal]

My build times seem to go up the more modules I break my app into. Right now its building 11 chunks.

$ ng serve --verbose

17745ms building modules                                                                 
110ms sealing
29ms optimizing
0ms basic module optimization 
0ms module optimization 
61ms advanced module optimization
223ms basic chunk optimization      
0ms chunk optimization 
0ms advanced chunk optimization 
0ms module and chunk tree optimization 
0ms module reviving 
104ms module order optimization
10ms module id optimization
0ms chunk reviving 
9ms chunk order optimization 
17ms chunk id optimization
291ms hashing
1ms module assets processing 
532ms chunk assets processing
2ms additional chunk assets processing 
1ms recording 
0ms additional asset processing 
107719ms chunk asset optimization
19ms asset optimization
804ms emitting
Hash: d413fff1418e57a113f2
Version: webpack 2.4.1
Time: 127704ms

macOS Sierra Version 10.12.5
MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
Processor 2.9 GHz Intel Core i5
Memory 8 GB 2133 MHz LPDDR3

Incremental builds now take 20+ seconds.

[noguespi]

Same issue here, stuck at 92% chunk asset optimization, for like 10 sec.

I'm on a new very small project and with a quite powerfull hardware (4x3.7ghz/32G RAM/M2 SSD)

I think it is an important bug, like #1980 was because it's really painfull to wait several seconds for a simple rebuild.

[hccampos]

Chunk asset optimization is mostly the source maps being generated. Disable source maps and you get your rebuild times back to an acceptable level.

Webpack has several types of sources maps which buid much faster than "source-map" but they don't play well with Typescript.

[crain]

@hccampos is right. If I start with:

ng serve --verbose --proxy-config proxy.conf.json --sourcemaps=false

I get: 40147ms instead of 222443ms.

Problem now I can't do any debugging in my browser :-(.

[kmckinley]

I just updated from angular-cli v1.0.1 to v1.1.3 and started seeing this issue. Same issue where "chunk asset optimization" is the major issue. I may downgrade until it gets resolved.

ng serve --verbose

32853ms building modules                 
132ms sealing
17ms optimizing
0ms basic module optimization 
0ms module optimization 
25ms advanced module optimization
370ms basic chunk optimization      
0ms chunk optimization 
1ms advanced chunk optimization 
17ms module and chunk tree optimization
0ms module reviving 
133ms module order optimization
8ms module id optimization 
0ms chunk reviving 
5ms chunk order optimization 
46ms chunk id optimization
157ms hashing
2ms module assets processing 
396ms chunk assets processing
5ms additional chunk assets processing 
0ms recording 
0ms additional asset processing 
84444ms chunk asset optimization
31ms asset optimization
956ms emitting
Hash: ffb0e268a11087d960cf
Version: webpack 2.4.1
Time: 119622ms

macOS Sierra Version 10.12.5
MacBook Pro (15-inch, Mid 2015)
Processor 2.5 GHz Intel Core i7
Memory 16 GB 1600 MHz DDR3

[kmckinley]

So I think I figured what caused the issue with my project. I am curious if anyone else in this thread is using @angular/material and have recently updated it to 2.0.0-beta.7?

I revert everything back to how I had it and painstakingly updated each package individually. I found when I updated @angular/material from 2.0.0-beta.3 to 2.0.0-beta.7 this issue started. The initial ng serve load became a 120000 to 160000ms process, and then anytime I made .ts changes it would take 10000 to 15000ms to process.

I found a crappy workaround for my issue by also including any @angular/material module I use in a lazy loaded module in the app.module. Now the initial ng serve load takes 50000 to 70000ms and when I make any .ts changes it process it within 1000 - 2000ms! This, of course, is a horrible workaround and I'll remove those modules in the app.module when I'm doing a build.

[intellix]

nobody said it yet but apparently Webpack 2.3.3 contained a big performance regression as mentioned here: https://github.com/webpack/webpack/issues/4863
The guys are waiting for a fix to land in 3.0.x before updating to it and I'm guessing that'll fix this issue

[clydin]

Much has improved since CLI 1.0. The performance has been greatly improved overall (with more to come). If anyone is still observing issues, please open a new issue describing the problem.

[Son-Lam]

Hello, I am using v 1.7.0 and still having the same issue. It takes about 35 sec for me.

[vermadev95]

You can use this flag while compiling:
ng serve --source-map=false

It take 10sec to compile now while previously it was taking 32sec.
source-map is just used for debugging. So if not using debugger you can disable and compile. And while recompiling it will take lesser time I think so.

[angular-automatic-lock-bot[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._}