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. 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. Just updated 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. I am having serious performance issues as well. My build times seem to go up the more modules I break my app into. Right now its building 11 chunks.
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. 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.
Rocketfish rf-51sdcd drivers for mac pro. 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.
Angular Compiler Plugin
The old (left) and new (right) Lucidchart editor But, there was a big problem: load times. The Angular 2 version consistently took several seconds longer to load than the non-Angular version.
Over the summer, we worked with the Angular team to improve our load times. The end result of these efforts is that our new editor loads five seconds faster than it did before and one second faster than our old editor. We even created a 29KB Hello World Angular 2 app along the way. The Problem When we released the beta of the Angular 2 version of our editor, we consistently saw load times about four seconds slower than our old editor.
Load times for our old editor (purple) vs our new editor (blue) for the week of July 10th. While analyzing our load times, we found that a large amount of time was being spent bootstrapping the Angular app with the runtime template compiler. We saw mentions of an offline compiler, but it did not appear to be available or documented yet. In an attempt to improve our load times, we reached out to the Angular team in March about Ahead of Time (AoT) compilation.
They kept us up to date on the progress of the AoT compiler and informed us that it only worked with TypeScript. Problem was, we were using the JavaScript version of Angular 2 in concert with the to typecheck and minify our JavaScript.
When we mentioned to the Angular team our inability to use TypeScript due to the Closure Compiler, they suggested two tools they built at Google to solve this same problem:. The Solution The Angular team built two tools to use TypeScript with the Closure Compiler: Tsickle and Clutz. Tsickle produces Closure annotated JavaScript from TypeScript, and Clutz produces TypeScript definition files from Closure annotated JavaScript. Together, they enable you to use TypeScript in a Closure compatible codebase, and vice versa. At Lucid, we modified Angular 2, its dependencies, and the AoT compiler in order to produce Closure compatible JavaScript from Angular 2 TypeScript. The end result is a five second improvement in load time for our new editor.
The above figure shows load times from May to September for our old editor (purple) and our new editor (blue). We switched from JavaScript to TypeScript with simple optimizations from the Closure compiler in the middle of August, which is when we see the first dip in load times. The second dip comes at the end of August, when we got Closure’s advanced optimizations working with TypeScript. Currently, we see load times about five seconds lower, on average, with AoT compilation than with runtime compilation.
The new load times are even about one second faster, on average, than our old editor. Load times for our old editor (purple) vs our new editor (blue) for the week of Aug 29th. When we compare flame graphs collected while loading our new editor with AoT and runtime compilation, we see a large difference. The biggest difference is, as expected, between the Angular 2 bootstrap and the first Angular 2 tick. The ahead of time compiler cuts out a large amount of template parsing and compilation that otherwise happens at runtime. Accordingly, things are much faster.
Fair warning, the scales on these graphs are not equal. Example application using Tsickle and Clutz In order to support Angular 2 generating Closure compatible JavaScript with AoT compilation, we modified Angular 2 and RxJS. We built a custom version of both projects and currently use them in our build process.
Angular Edge Slow
If you would like to know more about the modifications we made to get this working,. The 29 KB Hello World App Lucid built a proof of concept Hello World Angular 2 application using Tsickle and Clutz before we tried implementing the same thing in our large JavaScript codebase. You can find the example on GitHub at. The purpose of the project is to provide an example of Tsickle, Clutz, and Angular 2 working together.
Things are built from source, so you can see how we go from modified Angular 2 all the way to the final product. Comments, questions, and pull requests are welcome. When we compress the resulting bundle using Brotli, the final bundle size is right around 29KB. gzip is not far behind: $ ll -block-size=KB -rw-rw-r- 1 james james 115kB Sep 27 02:45 main.js -rw- 1 james james 29kB Sep 27 02:45 main.js.brotli-11 -rw-rw-r- 1 james james 35kB Sep 27 02:45 main.js.gz How to Run the Example More information can be found in the example’s README, but to run the example, either: 1. Docker docker pull jjudd/closure-typescript-example docker run -t -i -p 8000:8000 -net=host jjudd/closure-typescript-example localhost:8000/index.html?compiled=1 2. Build it Yourself make run Note: You will need to make sure you have all the dependencies installed for this to work.
Angular Compiler Options
It has only been tested on Ubuntu 14.04.