angular: Significant slow down in JIT after upgrading to version 4

I’m submitting a … (check one with “x”)

[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior Initial bootstrap time doubled (JIT mode)

Angular Version 2:

image

Angular Version 4:

image

The JitCompiler._compileComponents takes a lot of time. internally looks like generating the source maps is heavy.

Please tell us about your environment: OSX, webpack 2.2.1, ts 2.2.2

  • Angular version: 4.0.0

  • Browser: Chrome 57.0.2987.133 (64-bit)

  • Language: ts 2.2.2

cc @tbosch

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 10
  • Comments: 40 (27 by maintainers)

Most upvoted comments

The problem is that NG team dropped the ball on JIT and AOT is nowhere near complete. I works poorly for dev, only works for typescript, creating libraries is a nightmare with metadata.json.

Would it hurt to have performant JIT?

@ericmartinezr I wouldn’t consider opening an issue for a 1 sec gap on JIT.

But this is from 3.5 sec bootstrap on V2 to 7+ sec bootstrap on V4 - that is a big issue.

Clearly something is off, either my webpack setup or I dont know…
Problem is, I checkout the revision before the upgrade, its 3.5s after the upgrade 7+ secs but the upgrade didn’t include significant change other then v4…

This is not a small app, it comes with material and a baseline page for all of the material components we restyled… + a lot of pages 😃

UPDATE - ISSUE FOUND (in my setup):

Since facing this issue we used enableProdMode(); in our dev environment otherwise we can’t work. I removed it now to find out that now its fast, 2-3 seconds to load.

Checked out the git revision from the day I posted this issue, delete node_modules, yarn install - NOW BACK TO SLOW

After long revision/package install/test I found a potential suspect, it was a 3rd party angular component.

By removing @swimlane/ngx-datatable (cc @amcdnl) the bootstrap speed got down to 2.5 - 3.5 seconds

We moved to the new table implementation from material a week ago so we removed the entire code related to ngx-datatable

What’s more strange is that to reproduce all I had to do was install ngx-datatable and

import { NgxDatatableModule } from '@swimlane/ngx-datatable';
console.log(NgxDatatableModule)

Nothing more, not included in an @NgModule and no template/style/component code.

(testing on ngx-datatable 7.3.0 and 9.1.0 same results)

This is very strange since that lib is quite popular and this should have been reported from angular@4.0.0 beta/rc releases and surely the official.

My best guess is that this is a mix of 2 libraries, one of which is ngx-datatable and the other is one of the libraries I use.

@sebastianvog , @kemsky (and other users experiencing slowness) are you using ngx-datatable?

Any update on this? Our app is considerably slower in dev mode since Angular4.

Sorry to hijack this discussion but what happened to JIT?

JIT used to be very fast during RC days. It did what the name suggests and it “just-in-time” compiled what was needed on the fly. Somewhere before Angular 2 final is changed to “let’s compile everything on startup”.

This meant that our startup times went from sub second to 4-5s and we were forced to go the AOT way which we spent a lot of time on as it has very hairy corner cases.

Does this issue suggest that JIT got even worse in Angular 4? That is disappointing. Angular is not usable without AOT in production at the moment and the slow JIT makes development experience miserable becase refreshes are quite frequent when working on a code base with watchers.

/rant

This is profile for our application, using 4.0.2: bootstrap

Bootstrap time 6480.77 ms

179 components, 34 directives, a couple of pipes

I had to put application bundle into <script async> otherwise it stalls on parsing bundle (3+ MB)

Also, chrome can cache pre-compiled script, so you need to clear cache and run test again.

Firefox profiler: firefox_calltree firefox_gc