Angular Compiler Is Really Slow
Windows 7, 8 or 10. Linux (which distribution).
If you require further information just ask, I would really love for this one to get. After upgrading to Angular 4.1.3, the compilation of the same project takes 18-26. May 29, 2017. Is of course not the main culprit of AngularJS being viewed as a slow framework. So Angular guys in the newer framework decided to provide less flexibility. And introduced a JIT and AOT compilers and static templates.
Mac OSX (Yosemite? El Capitan?) Windows 10. Versions. Please run ng -version. If there's nothing outputted, please run in a Terminal: node -version and paste the result here: angular-cli: 1.0.0-beta.11-webpack.8 node: 6.3.0 os: win32 x64.
Angular Jit Compiler
Repro steps. Was this an app that wasn't created using the CLI? What change did you do on your code? App created with 1.0.0-beta.11-webpack.2 and later on upgraded to 1.0.0-beta.11-webpack.8 with appropriate changes. The log given by the failure. Normally this include a stack trace and some more information. The slow behavious is observed when upgraded from 1.0.0-beta.11-webpack.2 to 1.0.0-beta.11-webpack.8.
Install Angular Compiler Cli
Mention any other details that might be useful. Slow behavious reproduceable in following repo: I have experience this on two operating systems, windows 7 and windows 10. Has anyone else experieced this? For me rebuilds are dramatically slow, taking roughly 7-8 seconds which on same machine with cli version webpack.2 was taking rougly 2-3 seconds.
+1, new to angular2. I really like how it was easy to get started, sadly, keeping going is much harder. Every time I modify a file and save, it takes more than 10 seconds before I can reload the browser and see my update. For web development, I can't do this.
Maybe I'll switch to Angular2 JS. Here is what I see in my shell on ubuntu: webpack: bundle is now VALID. Webpack: bundle is now INVALID.
With beta.17 I registered a 6633ms second rebuild time, is this in line with your experience? Webpack: bundle is now INVALID. I also noticed rebuilds are about two times faster when I upgraded from beta.16 to beta.17; with average of 4 seconds. I'm still new to webpack world, so I don't yet really understand how things work internally, but after a quick search I found. Is this what's slowing down CLI's build process? I used custom gulp build process few months ago and had average 250ms rebuild times, so even 3-6 seconds with CLI is quite a setback;( Also, bit off topic, is it possible to isolate app code from vendor code in dev builds?
Would that speed things up? I see the similar issue and 'ng serve' on any small sccs change reports these optimizations steps. It is very very slow. See the output: webpack: bundle is now VALID. Webpack: bundle is now INVALID.
I run it with an NPM command that calls 'ng serve -aot=true -proxy-config proxy.conf.json': 'startNoServer': 'concurrently -kill-others 'ng serve -aot=true -proxy-config proxy.conf.json ', I played with a project that split the vendor bundle into a separate webpack script that didn't watch for changes. (it's rarely changed), I think it was all dealing with webpack without the CLI though. Is something like that possible with the CLI (it adds so much functionality and ease of use I'd take it over a faster build and setting up webpack myself!). Ah, so I should turn it off when developing.
I guess I'd have to be careful to not cause any changes that would break an AoT production build. Gets it down to 36 seconds build time, 5 second rebuild time - which is great! I guess I'll have to be careful not to do anything that could break AoT though (interestingly, turning it off highlighted a few errors, a service not marked as , no idea how that worked with AoT on!).
Seems my method of creating Modal dialogs is completely broken, but there's a guide here I'll give a good read. I'm having the same issues. Build takes 30 seconds on average.
Yes, I'm using ng serve, without any options and it was slow from the very beginning (clean ng cli). I'm using Vagrant for development environment. I guess it could slow it down a bit, but I wouldn't expect this much. It seems that it is compiling all modules everytime (even those from /nodemodules) and doing chunk asset optimizations (probably for all assets). Is it developed that way or I am missing something in my configuration?
@angular/cli: 1.0.0 node: 6.10.0 os: linux x64 @angular/common: 4.0.2 @angular/compiler: 4.0.2 @angular/core: 4.0.2 @angular/forms: 4.0.2 @angular/http: 4.0.2 @angular/platform-browser: 4.0.2 @angular/platform-browser-dynamic: 4.0.2 @angular/router: 4.0.2 @angular/cli: 1.0.0 @angular/compiler-cli: 4.0.2.
This article was published in 2016 when Angular CLI was relatively new. It has become very robust and fast now.
I have recently started exploring Angular 2 territory. I was not a big fan of typescript earlier but after spending a week or more on it, I must say, I have found it to be freaking good. After writing couple of small applications from ground zero and getting enough knowledge of basic bootstrapping, I decided to move on to Angular CLI (A command line interface for Angular 2.
I was working on Angular CLI at the time of writing this article. Things might change in future. Angular CLI is slow on Windows As you all know Angular CLI is built on top of Ember CLI. As of now it’s just a prototype of how Angular CLI would look like but we are getting towards final release. One thing I noticed, it took me 27-30 seconds to build or serve the simple hello world package. As usual, first thing I did is googled about performance issues with Angular CLI, all I found was irrelevant articles or Github issues. After digging a little deep, I figured out what the bottleneck was.
Ember CLI (on top of which Angular CLI is built) generates temporary files via code transpilers. The number of these small temporary files is in thousands. In the meanwhile, Windows Defender and Indexing service lock these temporary files to examine them. In ideal world scenario, this is considered as the safest option. We know these files are not harmful and can be skipped from being watched by these services. Fortunately, there are people in open source communities who have created an easy solution for this.
Here’s how you can improve the build time – Install “ember-cli-windows” package Open Command Prompt and type these commands –.