angular-cli: Rebuild extremely slow

Should this be bumped as critical? It seems to impede peoples productivity and maybe scare new comers to angular-cli.

@hansl just added a massive performance increase in https://github.com/angular/angular-cli/pull/4145.

For a brand new project, times for ng serve third rebuild are 65% smaller :

// before
Average time: 1922.2
Results: 1939,1920,1983,1885,1884

// after
Average time: 679.6
Results: 660,677,692,671,698

On a medium sized project:

// before
Average time: 4224.2
Results: 4244,4255,4258,4220,4144

// after
Average time: 1559
Results: 1537,1575,1525,1557,1601

@mrlund yes it will be included in the next release.

I just discovered that the awesome-typescript-loader forkChecker option isn’t being passed properly, so it’s not forking and type checking is happening inline. Changing useForkChecker to forkChecker in the webpack config drops reload time on a pristine project from ~4sec to ~1.5sec for me. I’ll prepare a PR right now.

@asadsahi @clydin that seems to be a very relevant improvement. I’ll add ts-loader to the list of scenarios I’m benchmarking as well.

+1 Rebuilds are extremely slow for me on OSX 10.11.6

Same issue here.

We aim to please 😄

https://github.com/angular/angular-cli/pull/3943 should help with the rebuilds of global CSS.

Running ng test is excruciatingly slow. It takes quite some time to detect there are changes and then re-run them.

New project with 79 tests:

Single/first run: ~90s Changes:: ~12s Changes after using for some time before it crashes:: ~20s

As @guiomie said, the numbers don’t add up for serving either: 638+10+1+3+200+1+17+121+149+3+6+18+78+83+3+6+1047 = 2384ms but says 6080ms so seems to be 3696ms going somewhere else.

+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.
1337ms building modules                                                       
19ms sealing
1ms optimizing 
0ms basic module optimization 
468ms module optimization
3ms advanced module optimization 
56ms basic chunk optimization       
0ms chunk optimization 
0ms advanced chunk optimization 
51ms module and chunk tree optimization
900ms module reviving
8ms module order optimization 
11ms module id optimization
9ms chunk reviving 
2ms chunk order optimization 
44ms chunk id optimization
212ms hashing
1ms module assets processing 
0ms chunk assets processing 
11ms additional chunk assets processing
0ms recording 
1ms additional asset processing 
0ms chunk asset optimization 
1618ms asset optimization
1ms emitting 
Hash: 8e4aceb7595d757b77f1
Version: webpack 2.1.0-beta.22
Time: 12081ms
           Asset     Size  Chunks       Chunk Names
  main.bundle.js  4.04 MB    0, 2       main
styles.bundle.js  10.2 kB    1, 2       styles
       inline.js  5.53 kB       2       inline
        main.map  4.31 MB    0, 2       main
      styles.map    14 kB    1, 2       styles
      inline.map  5.59 kB       2       inline
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  3.69 kB       0  

Do the assets really have to be optimised every time even if none of them have changed? A better approach would be to somehow cache the optimised assets if we need tp rebuild them every time to avoid repetition of the optimization.

5269 ms to reload on simple changes on OS X El Capitan with clean ng new

I am going to close this issue as we have done pretty much everything possible on our side to reduce rebuild time in development. We’re actively working with Webpack to improve performance on their side, and you should expect more as they release improvements on their side.

Hey all, I’ve been running some benchmarks with recently added features in the CLI master branch.

• https://github.com/angular/angular-cli/pull/3181 @ngtools/webpack as the TS loader for both AoT and non-AoT builds, across the board improvement.
• https://github.com/angular/angular-cli/pull/3113 --sourcemap flag (defaults to true): uses sourcemaps on builds. Disabling it improves performance.
• https://github.com/angular/angular-cli/pull/3117 --vendor-chunk flag (defaults to true): separates all non source files into vendor.bundle.js. Enabling it improves performance.

You can see them below:

• using a new project (small project): https://gist.github.com/filipesilva/ede674667714a3497951b1d030f7e134#file-new-project-txt
• using Ames (medium-sized project): https://gist.github.com/filipesilva/ede674667714a3497951b1d030f7e134#file-ames-txt

Baseline performance for ng serve, especially on rebuilds, should drastically improve across the board starting v1.0.0-beta.22.

Some users have also reported that turning off progress logging improved their build and rebuild times, but I could not verify that on my machine so I think it’s setup dependant. https://github.com/angular/angular-cli/pull/2858 lets you turn it off via --no-progress.

P.S.: The medium project benchmark showed a performance regression for --aot builds, but we’re working on fixing it.

@filipesilva 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 https://github.com/TypeStrong/ts-loader/issues/78. 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?

@filipesilva so downloaded the angular2-webpack-starter and quickly made our app work. Rebuilds take 1.5s-1.8s compared with 3.5s-17s in angular-cli. The initial build (after the dll had been created in another build) took 17s. That is compared with the 45s-60s for npm starting angular-cli.

@hccampos Question is do we really need that strict checking all the time? IDEs do most of this already. I’ve been working on an app for past 3 months with 2-3 major architectural changes and quite large refactoring each time. After all that, building the same app with isolatedModules turned off this morning I got only one import error in obscure DevComponent I rarely use.

I think it would be good idea to turn on isolatedModules flag with ng serve and off for ng build and other stuff…

Another update: moving to webpack@2.2.0-rc.3 (https://github.com/angular/angular-cli/pull/3786) seems to have had roughly a 30% performance (1.69s to 1.3s) increase in rebuilds.

BTW, The slow rebuild issue mentioned here was becasue I was using awesome-typescript-loader. ts-loader seems to be 4 times faster. Raised with awesome-typescript-loader owner to see if any particular option has been missed.

I also have a very slow “chunk assert optimization” step (~8s all the time even for small changes in one file). looking at https://github.com/webpack/webpack/issues/539#issuecomment-111275792 it seems it could be due to the source-map configuration chosen.

But now I realize, Webpack Dev Server keeps saying, nothing has changed, when in fact things have changed. Changes are not beeing picked up correctly. Am I missing something, or is this a new issue? When I quit devserver and ng serve again, changes are beeing picked up, automatic rebuild says “Nothing has changed” in the browser’s console. So it recognises that a file has been saved, but sees no difference. Changes in the html templates are considered, changes in my typescript files are not.

Try 28 guys. I’ve just compared my large project before and after and it’s so much faster than 40% as advertised.

b26: 3.3sec average on save b28: 1.0sec average on save

Also for those that were looking at DLLPlugin, our attempts show that it’s currently not possible to use together with lazy route detection.

@intellix @MickL I haven’t looked at SCSS much yet but will.

Guys, Having stats of roughly 2-3 seconds as rebuild time with angular-cli@beta22 on a beefy machine using ng serve --no-sourcemap --hmr -e=dev-hmr. Without sourcemaps? Really?

My personal opinion is that it is still not the ideal time we should be looking for. DLL is the only way out of having rebuild less than ~0.5 seconds to improve developer productivity. As I mentioned in few of my earlier comments that I have ~300-400ms as rebuild time in a non-cli project using(webpack2@beta27 with DLL). And this is with cheap-module-source-map enabled.

@intellix

With ts-loader:

With awesome-typescript-loader:

@rand0me as you just introduced me to Brunch and it caught my attention while looking at your stats. I tried this repo with angular and here are my stats:

> brunch watch --server
07 Nov 09:59:21 - info: application started on http://localhost:3333/
07 Nov 09:59:24 - info: compiling
07 Nov 09:59:24 - info: compiled 239 files into 3 files, copied index.html in 4.3 sec
07 Nov 10:00:03 - info: compiled home.component.html and 3 cached files into app.css in 234 ms
07 Nov 10:00:07 - info: compiled home.component.html and 3 cached files into app.css in 82 ms
07 Nov 10:00:14 - info: compiled home.component.html and 3 cached files into app.css in 93 ms
07 Nov 10:01:59 - info: compiled home.component.ts and 9 cached files into main.js in 106 ms
07 Nov 10:02:07 - info: compiled home.component.ts and 9 cached files into main.js in 98 ms

That is Nitro fast. 93ms with a html change and 106 ms with a typescript change.

Will it be correct to say that Brunch is on top of the list for recompiling assets, compared to webpack, systemjs, gulp etc at this point in time?

I tried using Brunch, and got that results:

$ brunch w -s
07 Nov 12:38:08 - info: application started on http://localhost:3333/
07 Nov 12:38:11 - info: compiling
07 Nov 12:38:12 - info: compiled 239 files into 3 files, copied index.html in 4.8 sec
07 Nov 12:38:57 - info: compiled home.component.ts and 9 cached files into main.js in 107 ms

It lacks of functional in comparison with angular-cli, but it is much faster. 💨

@guiomie we reserve critical for stuff like release bugs, or wholly broken commands. Stuff that usually needs a new release ASAP or no one can do anything.

We recognise that the slowness is crippling and are looking to solutions for it. It’s one of the things we want to address before RC1.

Hi, just wanted to say that I upgraded from beta 18 to 1.0.0 RC1, and the performance increase is spectacular, went from average rebuild of ~3-4 seconds to ~600ms-1000ms. I run “ng build --watch”. Great job on getting this to an acceptable level.

I’ve got an Asus Zenbook 12gb ram, SSD.

Massive improvement for me on Windows 10

beta26: ~12s beta28: ~2s

Thanks!

The problem is each time you save a file webpack will re-create the whole dependency graph of all the vendor and polyfill packages. On top of it, if you are doing this on an ntfs filesystem (windows) it will further increase the rebuild time.

I really wonder why you guys didn’t implement webpack.DllPlugin. Last week i created ng-x-cli. Well pretty much it is angular-cli with all its features i like topped with DllPlugin.

Feel free to check it out whoever still experience bad performance.

P.S: currently it doesnt have a test runner, because i dont write tests

@hansl @hccampos compilerOptions.isolatedModules is the one flag that can impact rebuild times in a huge way. I’m using custom gulp tasks for building (on top of CLI project) and if I set "isolatedModules": false rebuild times for just touching one file are 3.39s, 3.33s, 3.29s. with "isolatedModules": true I get 186ms, 73ms, 82ms. I’m not familiar with inner workings of webpack, so I’m not sure where/how this would affect other stuff, but I hope it helps (;

As mentioned by @filipesilva, the performance was nicely improved with the upgrade to Webpack 2 rc3 (rc4 released today, by the way). However, it is still not as good as it should be, imho. So I decided to do some quick profiling with node-nightly and the chrome dev tools. I haven’t had the time to really dig deep into it, but here are some screenshots of the profile I ran during a 3rd or 4th rebuild, without any file changes.

We can see that the great majority of the time is spent by typescript (and, up to a point, by Webpack) trying to figure out if a file or folder exists in order to properly resolve modules. This makes me wonder if it wouldn’t be possible to have TS and Webpack cache all the files and their locations (relative included) and only re-check them when there is a notification from the filesystem saying that a certain file has actually changed.

Say file A refers to file B and C. If only file A was changed in the filesystem, can check the imports and, if they didn’t change, we know that file B and C exist, we know exactly where they are and ideally we even have their contents in memory somewhere. If, say, only the reference to file B changed, then we can go look only for file B. And so on.

It may actually be the case that the normal watch mode of TSC actually does something similar to what I described above, even though I haven’t had the time to check. It is much faster than via webpack. However, I guess the webpack loader has a harder time because it is just calling TS to compile a certain file or set of files.

Anyone has any other insights? Maybe this could be something to bring up directly with Webpack and Typescript. What do you think?

@asadsahi @cdarken @rosslavery @simonech @gelliott181 thank you so much for all the benchmarks you did! As far as I can tell the CLI is somewhat slower than a barebones webpack run, but it’s usually not that much. So that really makes it seem like it’s a matter of system resources. I’m looking more into making DLLPlugin work on the CLI since that seems to be the only real big performance increase in sight.

@RicardoVaranda the asset optimization listed in the verbose build is actually not related to the assets folder at all. It’s related with stuff like sourcemaps, which is why that time drastically drops if you do --no-sourcemaps.

@hccampos I asked around and it turns out that happypack doesn’t work with loaders that use loaderContext._compiler. This, unfortunately, is pretty much all typescript loaders.

Guys, stop working, go home and rest and happy christmas and happy new year. 🎄 🎅 🎁

Hey all, I’ve been doing some more benchmarks to figure out if we have some gross inefficiencies in our webpack config.

To test that, I setup a very simple webpack app with lazy loading that uses @ngtools/webpack as the Typescript plugin. You can find it https://github.com/filipesilva/angular-cli-benchmark-app.

webpack-runner.js is a script that’ll modify the webpack config to have similar defaults as ng build/serve and to let you change it easily.

These are the benchmarks I got with that repo: https://gist.github.com/filipesilva/427b0369ccfc7d4d60b77aea90b71141#file-webpack-config-txt

The most significant one is the rebuild time:

Base command: npm start -- --serve
Comment: third rebuild time

Full command: npm start -- --serve
Average time: 2935.8
Results: 2787,3068,2706,3194,2924

I also rank the same app through a similar benchmark using the ng build/serve commands: https://gist.github.com/filipesilva/427b0369ccfc7d4d60b77aea90b71141#file-ng-txt

Base command: ng serve --no-progress
Comment: third rebuild time

Full command: ng serve --no-progress
Average time: 1693.4
Results: 1705,1672,1772,1718,1600

As far as my benchmarks show, there is no significant performance loss using ng build/serve versus using a plain webpack config. On the contrary even: rebuilds with the CLI take half the time.

To be honest this result surprised me as I expected most of our custom plugins and logic to take a toll on the build time.

So for me this validates the current config generation as performant as a simple webpack config, meaning there shouldn’t be any gross inefficiencies.

The next step is to try and integrate something like DLL Plugin, which should speed rebuilds up.

I had a go at it today, and you can even try it on https://github.com/filipesilva/angular-cli-benchmark-app with npm start -- --dll but am running into some problems with the lazy loaded chunks.

I also need to find a way to dynamically create the list of modules that will be included in the DLL bundle since users shouldn’t have to list them manually.

I’ll keep you posted on the progress, and if you have suggestions or optimisations I’d love to hear it.

Indeed, huge difference between beta 21 and beta 22. But Is that Ideal?

The point I am trying to make is that developer still waiting mostly for the 3rd party libraries. If a component.ts or component.html file is changed, recompilation should be quick. And DLL is the way to achive that.

All, new stats show ATL (3.0.0-beta.9) taking lead again:

With ts-loader:

With awesome-typescript-loader:

Means, ATL is taking lead in 3.beta9 again.

@mischkl there has been a large amount of activity on ts-loader in the last 2-3 weeks. the ts2.0 situation has changed and I noticed no rxjs issues when using it with fairly large project. There are still the issues I mentioned in my previous comment however.

@clydin 50% is massive difference. Is it worth switching to ts-loader in cli then?

In my case I don’t have to make any change to any path/configuration. Just replaced ATL with ts-loader.

#3011 merged which should help with build/rebuild times. Many thanks to @texel for finding this bug!

Hi! I have implemented the dll option for faster rebuilds. Check my fork to try it: https://github.com/kondi/angular-cli I have more than two times faster rebuild for the default empty project.

Excuse me if this is not the right place to post this, but does webpack use hot module reloading with “ng serve” on Windows? I’ve seen videos on youtube about angular 2 where only the file edited is reloaded instead of rebuilding all files, (in a Mac computer).

@rdwatters you could try this https://github.com/angular/quickstart. It’s a bit faster in my experience. It does not use angular-cli but could be appropiated for testing purposes

Also this could be of interest for anyone reading this:

Working with editors/IDEs supporting “safe write”

Note that many editors support “safe write” feature and have it enabled by default, which makes dev server unable to watch files correctly. “Safe write” means changes are not written directly to original file but to temporary one instead, which is renamed and replaces original file when save operation is completed successfully. This behaviour causes file watcher to lose the track because the original file is removed. In order to prevent this issue, you have to disable “safe write” feature in your editor.

VIM - set :set backupcopy=yes (see documentation) IntelliJ - Settings ▶︎ System Settings ▶︎ Synchronization ▶︎ disable safe write (may differ in various IntelliJ IDEs, but you can still use the search feature)

SOURCE: https://webpack.github.io/docs/webpack-dev-server.html

@intellix https://github.com/angular/angular-cli/pull/2840 should help with ng test. It makes code coverage and linting optional. On a test project with 100 component tests, total time went down from 90s to 30s.

Same here. Just write to subscribe to the thread. Environment: Intel i7, SSD Disk, Windows 10 => Initial Hello World compilation 15 seconds aprox. Recompilation after minimum changes: 6 seconds what makes it unpractial for agile development.

Using angular quickstart project from github without webpack gives me times of 300 ms for live-reloading. There must to be a way to choose not compiling during development and use bundling and minification only for production in my opinion.

@asadsahi with beta.17 I registered a 6633ms second rebuild time, is this in line with your experience?

webpack: bundle is now INVALID.
406ms building modules
15ms sealing
1ms optimizing
1ms basic module optimization
133ms module optimization
58ms advanced module optimization
49ms basic chunk optimization
1ms chunk optimization
0ms advanced chunk optimization
36ms module and chunk tree optimization
167ms module reviving
4ms module order optimization
9ms module id optimization
6ms chunk reviving
2ms chunk order optimization
39ms chunk id optimization
58ms hashing
4ms module assets processing
78ms chunk assets processing
5ms additional chunk assets processing
1ms recording
1ms additional asset processing
1992ms chunk asset optimization
532ms asset optimization
53ms emitting
Hash: ee2a562c10e2a5133f8d
Version: webpack 2.1.0-beta.25
Time: 6633ms
                                 Asset     Size  Chunks             Chunk Names
                      styles.bundle.js   173 kB    7, 9             styles
  25a32416abee198dd821b0b17a198a8f.eot  76.5 kB
  1dc35d25e61d819a9c357074014867ab.ttf   153 kB
 c8ddf1e5e5bf3682bc7bebf30f394148.woff  90.4 kB
e6cf7c6ec7c2d6f670ae9d762604cb0b.woff2  71.9 kB
                            0.chunk.js    36 kB    0, 9
                            1.chunk.js  16.9 kB    1, 9
                            2.chunk.js  21.8 kB    2, 9
                            3.chunk.js  9.87 kB    3, 9
                            4.chunk.js  14.5 kB    4, 9
                            5.chunk.js  11.9 kB    5, 9
                        main.bundle.js  4.42 MB    6, 9  [emitted]  main
  d7c639084f684d66a1bc66855d193ed8.svg   392 kB
                     scripts.bundle.js   466 kB    8, 9             scripts
                             inline.js  5.53 kB       9             inline
                                 0.map  30.7 kB    0, 9
                                 1.map    15 kB    1, 9
                                 2.map  18.8 kB    2, 9
                                 3.map  7.45 kB    3, 9
                                 4.map  13.3 kB    4, 9
                                 5.map  9.82 kB    5, 9
                            styles.map   236 kB    7, 9             styles
                           scripts.map   576 kB    8, 9             scripts
                            inline.map  5.59 kB       9             inline
                              main.map  4.66 MB    6, 9  [emitted]  main
Child html-webpack-plugin for "index.html":
         Asset    Size  Chunks       Chunk Names
    index.html  3.8 kB       0
webpack: bundle is now VALID.

+1 also quite slow on linux x64 after I moved my assets from the app folder to the appropriate assets folder, it now optimizes the assets folder every time I make a change to any of the code which seems to be the reason for the added delay.

Ng serve watches for changes and rebuilds only the changed chunks automatically. Killing the process each time forces a full build.

I have hello world project created with ng new HelloWorld

then I run ng build. Takes 62 seconds.

Then I change a line in hello world I run ng build, and it takes 62 seconds again. Is this normal? Is this how you develop?

That explains it. AoT is extremely slow, too slow to be used while developing.

@hanvyj What’s your command line look like?

@hanvyj build or rebuild? Our build times are now at nearly two minutes. Rebuilds are at 3s for no changes up to 30s in some cases. Did some profiling and it is mostly the source maps which are insanely slow. Disable them and builds become way faster…while debugging becomes a nightmare. All in all, you are still quite lucky I think. If things get really bad, there is always the option of ejecting. We have been considering it for a while.

Totally agree with John. Great work! Thanks.

On Mon, Mar 6, 2017 at 1:52 AM, John Livingston notifications@github.com wrote:

I would also be remiss without giving serious kudos to the team. I’ve been updating regularly over the last few months and the last few builds have shown a massive performance increase. Huge thanks all!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/angular/angular-cli/issues/1980#issuecomment-284283953, or mute the thread https://github.com/notifications/unsubscribe-auth/AV1APdJ3JPHglkLsZZmR-FkicvzyjGTGks5ri2bJgaJpZM4J07P9 .

– Alban Xhaferllari PHP Developer User Team

I would also be remiss without giving serious kudos to the team. I’ve been updating regularly over the last few months and the last few builds have shown a massive performance increase. Huge thanks all!

Ok, I could fix that (with the fix of beeman described in #4329). But now, rebuild times are back at 15s with beta 28 on windows 7.

There is an open issue appeared with beta 28: https://github.com/angular/angular-cli/issues/4338

@asadsahi the starter you linked uses a different TS loader than we do here, and I think it can’t give complete static analysis information.

I’ll investigate further if the approach used in https://github.com/shlomiassaf/ng-router-loader could be used in the CLI.

@filipesilva DLLPlugin has been implemented in angular2-webpack-starter project recently using this webpack plugin. I like this idea as it is a pluggable way to add dll support. 3rd party packages are listed in that plugin as well. I have this working in one of my project too using same plugin. I have provided in the past stats of normal rebuild vs dll and performance is massive with DLL. And both projects have lazy routes there too.

Do we know what sort of challanges we are having with lazy routes?

@filipesilva we have the same experience in our company. Everyone.

Linux: 4sec Windows: 19sec.

Seems like NTFS (inodes) have serious performance issues with tons of small files

My idea was to use a similar strategy to the one we already use for the vendor chunk to determine DLL packages. Basically all top-level modules requested by the the main (and lazy loaded) chunks that are located in node_modules.

It might be enough initially to just hardcode the angular packages though.

At the moment I’m still blocked by some weird interactions between the AoTPlugin and DLLPlugin. Builds seem to break as soon as an angular lib is factored out into the DLL bundle.

@simonech It’s definitely way too much time, especially for an empty project. I really cannot fathom how could do that. Perhaps an overly aggressive antivirus, or a dying SSD…

You know anyone else with a similar Surface Pro that could try? For a brand new project you should be seeing numbers similar to https://gist.github.com/filipesilva/427b0369ccfc7d4d60b77aea90b71141#file-ng-txt

@khodeN of course ram disk makes the building way more faster. You can put the whole OS into a 1TB ram disk ,then you can fly! 😃

Alright , I am just kidding . So your exp probably proved that this is mostly an IO issue.

beta 22 is much better but still way too slow for my company to be able to consider uaing angular-cli yet.

@JohannesRudolph It’s on npm, just not marked as latest yet. You can check the current setup from terminal:

$ npm dist-tag ls angular-cli
experimental: 1.0.0-beta.22
latest: 1.0.0-beta.21

To test beta 22 right now, you have to follow https://github.com/angular/angular-cli#updating-angular-cli but change latest to experimental in the provided commands.

I’d like to try the improvements in beta.22, but is it just me or is beta.22 not on npm yet? Are there any plans for pushing it there?

ts-loader has received a large number of improvements over the last couple weeks and it appears that awesome-typescript-loader may be merging functionality back into it.

With the latest version of ts-loader (1.2.1 as of now) and a quick replacement in the CLI, I was able to see a ~50% improvement on rebuild times (initial build increased ~25%). Be aware that some loader options are named differently (tsconfig -> configFileName) and for tsconfig paths support the ATL paths plugin is still needed. It also seems to be pulling in the spec files (or at least type checking them); so that will need some investigation (the exclude line is still in the config).

NOTE: Production builds are broken with the change. The loader seems to have a conflict with the use of LoaderOptionsPlugin.

@intellix I have 2 projects, one cli based and a .net non-cli based. In my above comments numbers are from the .net one using latest beta version of webpack 2 (beta 26). Not sure how I can test this with cli based project, but I am asuming something worth trying replacing awesome-typescript-loader with ts-loader to see any difference.

@texel

Changing useForkChecker to forkChecker in the webpack config

Can we somehow test this in an existing cli based project?

Is this setting something we can try in a non-cli, webpack 2 based project? I have similar slow rebuilds issue in another project.

@filipesilva Brand new to all-things Angular. I just installed the Angular CLI and am going through the free introductory Angular 2 course on egghead.io. I’ve literally made 1 change to a component file, and the rebuilds are slow (not to be too redundant from everything in this thread):

angular-cli: 1.0.0-beta.18
node: 6.5.0
os: darwin x64

Bootingup ng serve I get...
Time: 8973ms

If I save index.html, I get...
Time: 3329ms 

Which isn't necessarily bad, but I haven't actually done anything with files yet:) 

I know this is still in beta, so please don’t take this negatively, but coming from Ember and React, I’ve never seen builds/reloads this slow. Should I hold off on using CLI for learning NG 2 until the process is a bit faster? I’m looking more for guidance than I am trying to criticize the project. Thanks!

same here , it’s too slow!

angular-cli: 1.0.0-beta.17
node: 6.6.0
os: darwin x64

Version: webpack 2.1.0-beta.25
Time: 8100ms
            Asset       Size  Chunks             Chunk Names
   main.bundle.js    3.12 MB    0, 2  [emitted]  main
 styles.bundle.js    10.2 kB    1, 2  [emitted]  styles
        inline.js    5.53 kB       2  [emitted]  inline
         main.map    3.19 MB    0, 2  [emitted]  main
       styles.map    14.2 kB    1, 2  [emitted]  styles
       inline.map    5.59 kB       2  [emitted]  inline
       index.html  480 bytes          [emitted]  
assets/.npmignore    0 bytes          [emitted]  
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  2.81 kB       0       
webpack: bundle is now VALID.

https://github.com/angular/angular-cli/pull/2570 moved away from CopyWebpackPlugin to a simpler glob copy. This should help with @RicardoVaranda’s issue.