Rebuild extremely slow

OS?  Windows 7, 8 or 10. Linux (which distribution). 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

Repro steps. Was this an app that wasn't created using the CLI? What change did you
do on your code? etc.
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

Mention any other details that might be useful.
Slow behavious reproduceable in following repo:
https://github.com/asadsahi/ng2fb-bootstrap

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 Rebuilds are extremely slow for me on OSX 10.11.6

+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.

@TheLarkInn can you weigh in?

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.

Would DLL loading for vendor items help here? They must be 90% of bundle size

+1 build/rebuilds extremely slow, as well as the update/recompiling in the browser.
as well as ng test

+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

Same issue here.

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

@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.

And with latest master

@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?

250ms would be like a dream!
@filipesilva if I add all the ms in your run extract, we get: 3651ms total. There is still a 3 seconds missing right?
When I run ng-serve, change some code, save my file, the change from "webpack: bundle is now VALID" to "webpack: bundle is now INVALID", takes a few second. Could this be optimized also?

@sasxa we don't use ts-loader, but I skimmed the issue and didn't find anything we could apply to the CLI.
@guiomie I am not too sure of how the numbers add up. All of that is handed over to webpack.
I also asked @TheLarkInn and there seem to be some incoming Webpack 2 optimizations that would help with speed.

@filipesilva  yes I can confirm that rebuilds are somewhere taking same amount of time and I also suspect its somewhere in webpack because I am having similar rebuild times in another non-cli based project based on webpack 2.
@sasxa webpack dll is for the purpose of separating vendor from application files for speeding up rebuilds.

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.
536ms building modules
6ms sealing
0ms optimizing
1ms basic module optimization
126ms module optimization
1ms advanced module optimization
25ms basic chunk optimization
0ms chunk optimization
0ms advanced chunk optimization
13ms module and chunk tree optimization
79ms module reviving
2ms module order optimization
5ms module id optimization
4ms chunk reviving
1ms chunk order optimization
16ms chunk id optimization
47ms hashing
1ms module assets processing
1ms chunk assets processing
4ms additional chunk assets processing
0ms recording
0ms additional asset processing
0ms chunk asset optimization
825ms asset optimization
5ms emitting

ng version:
angular-cli: 1.0.0-beta.16
node: 4.5.0
os: darwin x64

same here , it's too slow!
angular-cli: 1.0.0-beta.15
node: 6.6.0
os: darwin x64

Version: webpack 2.1.0-beta.22
Time: 7232ms

See #2651

@JanStureNielsen, that's not related to rebuild times but instead to initial npm installs.
I'm also experiencing the invalidation delay that @guiomie reported.  As well as files not being marked as changed.
@TheLarkInn, is there a plan to integrate watchman within webpack?  It is highly effective at what it does.

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

to chime in here with some data of a fairly small angular2 project:
angular-cli: 1.0.0-beta.17
node: 6.3.0
os: darwin x64

webpack: bundle is now VALID.
webpack: bundle is now INVALID.
526ms building modules
5ms sealing
0ms optimizing
0ms basic module optimization
155ms module optimization
1ms advanced module optimization
6ms basic chunk optimization
0ms chunk optimization
0ms advanced chunk optimization
10ms module and chunk tree optimization
77ms module reviving
1ms module order optimization
3ms module id optimization
2ms chunk reviving
0ms chunk order optimization
11ms chunk id optimization
81ms hashing
1ms module assets processing
106ms chunk assets processing
4ms additional chunk assets processing
0ms recording
0ms additional asset processing
3427ms chunk asset optimization
596ms asset optimization
51ms emitting
Hash: 20f361734232b0bd829f
Version: webpack 2.1.0-beta.25
Time: 6997ms
           Asset     Size  Chunks             Chunk Names
  main.bundle.js  3.32 MB    0, 2  [emitted]  main
styles.bundle.js   138 kB    1, 2             styles
       inline.js  5.53 kB       2             inline
      styles.map   182 kB    1, 2             styles
      inline.map  5.59 kB       2             inline
        main.map  3.39 MB    0, 2  [emitted]  main
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  2.81 kB       0

Running ng test is excruciatingly slow. It takes quite some time to detect there are changes and then re-run them. I've got a new project with 79 tests and a single run takes 1.5min to run. It seems like there's about 1.x minute before Chrome is even opened:
$ time ng test --watch false
real	1m29.478s
user	1m1.751s
sys	0m14.134s

Just using the default ng new app takes about 3 seconds to reload.  Is there a way to limit the munging wepback is doing to speed this up?  Even if just for live reload scenarios.

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

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.

@YagoLopez , if I look in the models/webpack-build-developement.js , it looks like minification is disabled:
plugins: [
            new webpack.LoaderOptionsPlugin({
                options: {
                    minimize: false,
                    tslint: {
                        emitErrors: false,
                        failOnHint: false,
                        resourcePath: path.resolve(projectRoot, appConfig.root)
                    },
                }
            })
        ],

@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.

Also thanks to all that are posting their numbers, it's very useful to get a benchmark. @intellix's report is specially worrying imho.

@filipesilva thanks for your job, i undertand the complexities of the problem. I guess it is question of time.
@guiomie thanks for the info, but then, source map files should't be created in the process of compilation. If I'm not wrong they do are created. Anyway with minification or not its too much time in my opinion. I guess this problems will be solved in future versions. Cheers.

@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.

@filipesilva that sounds useful, at least as it makes a lot of sense to (optionally) skip coverage reporting when running ng test --watch=true
I'm still not sure though why webpack spends so much time in "chunk assets optimization". Might be a webpack related issue after all.

@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!

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

Some additional statistic from me. Updating takes 20 seconds for me.
webpack: bundle is now INVALID.
 50% building modules 2/3 modules 1 active ...sers\user-edit\user-edit.component.tsweb
pack: wait until bundle finished: /settings
1339ms building modules
1457ms sealing
0ms optimizing
1ms basic module optimization
100ms module optimization
3269ms advanced module optimization
24ms basic chunk optimization
0ms chunk optimization
0ms advanced chunk optimization
530ms module and chunk tree optimization
384ms module reviving
3ms module order optimization
48ms module id optimization
129ms chunk reviving
1ms chunk order optimization
503ms chunk id optimization
110ms hashing
1ms module assets processing
142ms chunk assets processing
12ms additional chunk assets processing
0ms recording
1ms additional asset processing
6849ms chunk asset optimization
1570ms asset optimization
397ms emitting
Hash: 9db8a41caee5835af84d
Version: webpack 2.1.0-beta.25
Time: 20520ms
           Asset     Size  Chunks             Chunk Names
           0.map   117 kB   0, 30
      0.chunk.js  95.5 kB   0, 30
      2.chunk.js   210 kB   2, 30
      3.chunk.js  1.16 MB   3, 30
      4.chunk.js  18.4 kB   4, 30
      5.chunk.js  20.6 kB   5, 30
      6.chunk.js   115 kB   6, 30
      7.chunk.js  70.6 kB   7, 30
      8.chunk.js  96.1 kB   8, 30
      9.chunk.js    13 kB   9, 30
     10.chunk.js  54.2 kB  10, 30
     11.chunk.js  40.1 kB  11, 30
     12.chunk.js   177 kB  12, 30
     13.chunk.js  15.8 kB  13, 30
     14.chunk.js  11.8 kB  14, 30
     15.chunk.js  19.4 kB  15, 30
     16.chunk.js  9.67 kB  16, 30
     17.chunk.js  34.8 kB  17, 30
     18.chunk.js  16.7 kB  18, 30
     19.chunk.js  18.9 kB  19, 30
     20.chunk.js  66.2 kB  20, 30
     21.chunk.js  11.4 kB  21, 30
     22.chunk.js  56.3 kB  22, 30
     23.chunk.js   410 kB  23, 30
     24.chunk.js  64.7 kB  24, 30
     25.chunk.js  2.44 kB  25, 30
     26.chunk.js  33.2 kB  26, 30
     27.chunk.js   238 kB  27, 30
  main.bundle.js  6.75 MB  28, 30  [emitted]  main
styles.bundle.js  12.9 kB  29, 30             styles
       inline.js  5.53 kB      30             inline
      1.chunk.js   315 kB   1, 30
           1.map   415 kB   1, 30
           2.map   248 kB   2, 30
           3.map  1.26 MB   3, 30
           4.map  22.3 kB   4, 30
           5.map  24.6 kB   5, 30
           6.map   146 kB   6, 30
           7.map  91.1 kB   7, 30
           8.map   118 kB   8, 30
           9.map  18.4 kB   9, 30
          10.map  69.8 kB  10, 30
          11.map  46.3 kB  11, 30
          12.map   217 kB  12, 30
          13.map  20.5 kB  13, 30
          14.map  14.8 kB  14, 30
          15.map  23.3 kB  15, 30
          16.map  12.6 kB  16, 30
          17.map  40.4 kB  17, 30
          18.map    20 kB  18, 30
          19.map  22.1 kB  19, 30
          20.map  79.1 kB  20, 30
          21.map  13.8 kB  21, 30
          22.map  66.7 kB  22, 30
          23.map   494 kB  23, 30
          24.map  77.2 kB  24, 30
          25.map  3.16 kB  25, 30
          26.map  41.5 kB  26, 30
          27.map   295 kB  27, 30
      styles.map  17.6 kB  29, 30             styles
      inline.map  5.59 kB      30             inline
        main.map  7.31 MB  28, 30  [emitted]  main
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  6.11 kB       0
webpack: bundle is now VALID.

Just wanna add some information to help others with testing:
fdescribe, fit, xdescribe, xit are your friends for only running particular tests :) http://jasmine.github.io/2.1/focused_specs.html

First of all, thanks for the great work all. Was hoping Node 7 upgrade might help, but it was only marginal. Would love to see this sped up as well. For example, the following similar project is on the React side, but rebuilds in about 1/4 the time. https://github.com/davezuko/react-redux-starter-kit

I experience the same Problems on my mac with OSX 10.11.6. Updates take 13secs for me.
What is your idea on solving this? With plain webpack I'd probably try to improve performance by separating the build of the libraries and the build of my own files using the dll approach.
My numbers are btw. the following:
webpack: bundle is now INVALID. 354ms building modules                                                              5ms sealing  0ms optimizing  0ms basic module optimization  119ms module optimization 0ms advanced module optimization  13ms basic chunk optimization        0ms chunk optimization  0ms advanced chunk optimization  38ms module and chunk tree optimization 172ms module reviving 1ms module order optimization  3ms module id optimization  7ms chunk reviving  0ms chunk order optimization  47ms chunk id optimization 67ms hashing 1ms module assets processing  98ms chunk assets processing 4ms additional chunk assets processing  1ms recording  0ms additional asset processing  3092ms chunk asset optimization 7742ms asset optimization 69ms emitting Hash: 8065f4ec0d2feed80685 Version: webpack 2.1.0-beta.25 Time: 13361ms                                  Asset     Size  Chunks             Chunk Names   f24134ff542a345f5af1c3e616872d8b.svg  12.8 kB                        f4769f9bdb7466be65088239c12046d1.eot  20.1 kB                        c3572dbbb07e826429824fe22f049c73.eot    48 kB                        55ed4dcca47c6b224f2ed1536524f6ed.svg  71.7 kB                       78bb38012b6093e39a98a8a5270f81f6.woff  55.2 kB<PHONE_NUMBER>7bd7575d6327160d64e760.svg   109 kB                        e18bbf611f2a2e43afc071aa2f4e1512.ttf  45.4 kB                       fa2772327f55d8198301fdb8bcfc8158.woff  23.4 kB                        ff22e7b0d9516041df8efa602e806bfc.eot  3.62 kB                      448c34a56d699c29117adc64c43affeb.woff2    18 kB                                              main.bundle.js  4.97 MB    0, 2  [emitted]  main                       styles.bundle.js   228 kB    1, 2             styles                              inline.js  5.53 kB       2             inline                             styles.map   289 kB    1, 2             styles                             inline.map  5.59 kB       2             inline                               main.map  5.28 MB    0, 2  [emitted]  main Child html-webpack-plugin for "index.html":          Asset     Size  Chunks       Chunk Names     index.html  3.83 kB       0        webpack: bundle is now VALID.

Not sure how it would be implemented, or if it's already possible? but If I could exclude rebuilding all node_modules/* from the 'ng-build' command, and just 'compile' my changed partials/js/css files I think that would reduce my build-time considerably. It's not often I'd need to rebuild the node_modules.

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.

@kondi tried linking your repo to one of playground project, but cannot see reasonable difference of rebuilds, here are the stats:
Before:
Version: webpack 2.1.0-beta.25
Time: 4127ms
                                 Asset     Size  Chunks             Chunk Names
                      styles.bundle.js   183 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   456 kB    0, 9
                            1.chunk.js  36.4 kB    1, 9
                            2.chunk.js  21.9 kB    2, 9
                            3.chunk.js  9.89 kB    3, 9  [emitted]
                            4.chunk.js  14.5 kB    4, 9
                            5.chunk.js  11.9 kB    5, 9
                        main.bundle.js  3.81 MB    6, 9             main
  d7c639084f684d66a1bc66855d193ed8.svg   392 kB
                     scripts.bundle.js   461 kB    8, 9             scripts
                             inline.js  5.53 kB       9             inline
                                 0.map   570 kB    0, 9
                                 1.map  31.4 kB    1, 9
                                 2.map  18.8 kB    2, 9
                                 4.map  13.3 kB    4, 9
                                 5.map  9.82 kB    5, 9
                              main.map  3.97 MB    6, 9             main
                            styles.map   248 kB    7, 9             styles
                           scripts.map   570 kB    8, 9             scripts
                            inline.map  5.59 kB       9             inline
                                 3.map  7.45 kB    3, 9  [emitted]
Child html-webpack-plugin for "index.html":
         Asset    Size  Chunks       Chunk Names
    index.html  3.8 kB       0
webpack: bundle is now VALID.

After:
ersion: webpack 2.1.0-beta.25
Time: 3508ms
                                 Asset     Size  Chunks             Chunk Names
                      styles.bundle.js   186 kB    7, 9             styles
  25a32416abee198dd821b0b17a198a8f.eot  76.5 kB
  1dc35d25e61d819a9c357074014867ab.ttf   153 kB
e6cf7c6ec7c2d6f670ae9d762604cb0b.woff2  71.9 kB
 c8ddf1e5e5bf3682bc7bebf30f394148.woff  90.4 kB
                            0.chunk.js   458 kB    0, 9
                            1.chunk.js  36.3 kB    1, 9
                            2.chunk.js  21.7 kB    2, 9
                            3.chunk.js  9.84 kB    3, 9  [emitted]
                            4.chunk.js  14.4 kB    4, 9
                            5.chunk.js  11.8 kB    5, 9
                        main.bundle.js  1.06 MB    6, 9             main
  d7c639084f684d66a1bc66855d193ed8.svg   392 kB
                     scripts.bundle.js   461 kB    8, 9             scripts
                      inline.bundle.js  5.53 kB       9             inline
                                 0.map   577 kB    0, 9
                                 1.map  31.6 kB    1, 9
                                 2.map    19 kB    2, 9
                                 4.map  13.4 kB    4, 9
                                 5.map  9.95 kB    5, 9
                              main.map   1.2 MB    6, 9             main
                            styles.map   252 kB    7, 9             styles
                           scripts.map   570 kB    8, 9             scripts
                            inline.map   5.6 kB       9             inline
                                 3.map  7.57 kB    3, 9  [emitted]
Child html-webpack-plugin for "index.html":
         Asset    Size  Chunks       Chunk Names
    index.html  3.8 kB       0
webpack: bundle is now VALID.

Time is lesser after linking, but sometimes with original angular-cli its roughly same.

For me in a freshly created ng new project the rebuild time is around 5000 ms without dll, 2000 ms using dll.
@asadsahi  I checked your repository on my laptop. Without dll the rebuild time is around 11500 ms, with dll I am getting 6600 ms. I can get 5200 ms if I move more libraries to the dll (angularfire2, ng-bootstrap, ng2-translate). Your numbers look much better by default already. Maybe because I am testing on windows? Or slow computer?

@kondi you might be right, I am just mentioning following times, as rebuild times.
Time: 4127ms
Time: 3508ms
Another thing I was just keeping an eye on was how quickly browser gets refreshed after rebuild, and couldn't see significant differences. It might be an just and illusion becasue I have another project based on webpack 1 with dll and that project's rebuild is 200-300 milliseconds, which I am hoping webpack 2 to have same stats one day :)

Your numbers look much better by default already. Maybe because I am testing on windows? Or slow computer?

Its definitely becasue testing I did was on my work machine which is and 8 core beefy machine. On my home laptop it comes down to same numbers (around 10+ seconds). Both work and personal machines are on windows BTW.

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.

@texel whoa that's impressive, great find! Let me know when that PR is up so I can review.

Funny that the whole reason of typescript is to not have this type of mistakes.
Similar improvement for me as well. From 5.5 sec to 2.2 sec. If you combine with dll option, ends up at 1.2 sec.

@filipesilva https://github.com/angular/angular-cli/pull/3008
Just getting the CLA sorted.

Just did a few numbers to check everything with 19-3:
Without texel's forkChecker fix
reload:

6,226ms
3,017ms
2,967ms
ng test:
9,000ms
6,500ms
6,500ms

With texel's forkChecker fix
reload:

4,060ms
1,797ms
1,748ms
ng test:
6,000ms
5,000ms
4,150ms

What's the lowdown on DLLs. To me it seems an obvious fix but still haven't heard anything from anyone about why it's not used. Any ideas @TheLarkInn?

I haven't tested the DLL, but have tested https://github.com/mzgoddard/hard-source-webpack-plugin and noticed no improvement almost.

https://github.com/mzgoddard/hard-source-webpack-plugin shouldn't be an improvement from an in-memory reload, but it should significantly reduce initial compile times.

@texel does this mean it'd always be notable in ng build?

DLL potentially complicates building the bundle (it has to be done in two steps, and the main bundle needs to be told how to reference the DLL) and it may slightly increase initial build time, but in my experience it's a win for dev speed and hopefully makes caching libs easier as well.

Yes, https://github.com/mzgoddard/hard-source-webpack-plugin seems like it improves builds after initial build.

The DLL option also severely limits webpack's tree-shaking ability.  So for production builds it's probably not the best option.
I've been experimenting with moving angular into a DLL as well.  While there is additional complexity, it seems an overall win for at least the dev serve use case.

@texel

Changing useForkChecker to forkChecker in the webpack config

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

@texel's tweak effectively cuts my build time in half and this is on a larger project. Well done!

@asadsahi certainly! If you're using awesome-typescript-loader you just need to make sure that forkChecker: true is passed in its query params. You'll also need to make sure to instantiate a new ForkCheckerPlugin and add it to the plugins array of your webpack config.

Opened a new PR to satisfy the googlebot: https://github.com/angular/angular-cli/pull/3011

@texel unfortunately this isnt't making any difference. Here is my repo:
This is my configuration:
forkChecker parameter:
module.exports = merge({
    resolve: {
        extensions: ['.js', '.ts']
    },
    module: {
        rules: [
            { test: /\.ts$/, exclude: [/\.(spec|e2e)\.ts$/], loaders: ['awesome-typescript-loader?forkChecker=true ', 'angular2-template-loader'] },
            { test: /\.html$/, loader: "html" },
            { test: /\.css/, loader: extractCSS.extract(['css']) },
            { test: /\.scss$/, loaders: ['raw-loader', 'sass-loader?sourceMap'] },
            { test: /\.json$/, loader: 'json-loader' },
            {
                test: /\.woff(\?v=\d+\.\d+\.\d+)?$/,
   ............for brevity

Plugin added:
  plugins: [
        extractCSS,
        new webpack.DllReferencePlugin({
            context: __dirname,
            manifest: require('../wwwroot/dist/vendor-manifest.json')
        }),
        // To eliminate warning
        // https://github.com/AngularClass/angular2-webpack-starter/issues/993
        new webpack.ContextReplacementPlugin(
            /angular(\\|\/)core(\\|\/)(esm(\\|\/)src|src)(\\|\/)linker/,
            __dirname
        ),
        /*
            * Plugin: ForkCheckerPlugin
            * Description: Do type checking in a separate process, so webpack don't need to wait.
        */
        new ForkCheckerPlugin(),
        new webpack.DefinePlugin({
            'process.env': {
                'ENV': JSON.stringify(process.env.ASPNETCORE_ENVIRONMENT)
            }
        })

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

@asadsahi that should work for a Webpack 1 project- does Webpack 2 still support query params using the url-style syntax?

@texel not sure. But I also tried with following settings with no luck. Are these correct settings?
{
              loader: 'awesome-typescript-loader',
              query: {
                forkChecker: true
              }
            },

Besides this project, how can I test the merged PR change for fast rebuilds in an angular-cli based project right now? (any way I can target project using latest version of cli branch?)

@asadsahi of that I'm not sure. I tested it by manually editing the webpack-build-typescript.js file in my angular-cli installed in node_modules. Which version of awesome-typescript-loader do you have installed? If you can't get it working you might want to ask or open a ticket in that repo.

I've noticed some progress on this issue. @filipesilva Could you please update npm package? I have a big project with a lot of components and want to check rebuild time, because now it takes about 20-40 seconds.

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.  💨

@rand0me as 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.

Just a quick test I made today comparing the the https://github.com/AngularClass/angular2-webpack-starter:
Angular webpack: 1.5s with their base project
Angular cli: 4.1s with the ng new base project
Both run on MacOS 10.12.1

I tested gulp, brunch, and optimized angular cli (forkCheck), both on very small seed/template.

angular-cli : including forkCheck optimization I'm down to ~2-4 sec recompile time (~2 time faster than default).
angular class starter : 1.5~3.5 sec (it uses webpack)
gulp 2 sec when it recompile typescript (but very fast when to recompile html < 200ms).
brunch : I just discovered thanks to @rand0me :  ~120ms to recompile typescript !! This build tool looks very fast & simple to configure.

@serphacker, @asadsahi  I'm wondering, why people doesn't got it earlier😄
Now I'm trying to adopt a project, builded on top of angular-cli 1.0.0-beta.17 to build with Brunch
Things that I'm currently stuck to:

Can't do backward-compatible config, because of Brunch convetions
Can't make automatic injection of styles and scripts (to index.html)
Can't find Brunch plugin to support CSS @import concatenation
Also, it lacks a generate command, but it can be used from angular-cli 🙉

@rand0me since the whole universe is after webpack/angular-cli combinations, I am not sure its wise to individually mix something with this, unless a plugin model with angular cli allows to use any build/package manager like webpack, brunch.
However, as an alternative approach to pick Brunch for a project perhaps is worth trying (which I will try as well).
I am sure angular-cli team is trying to identify the possible cause of slow rebuild (like @texel found in terms of forkCheck), but I suspect its webpack 2 not working to best of its abilities. I have managed to get rougly 200-300ms of rebuilds times from Webpack 1 using DLLS in the past, but since I have upgraded the same project on webpack 2, its down to 5-6 seconds. Couldn't find a single project with webpack 2 and dll giving rebuilds in milli seconds (Love to see one). There is a similar issue I have raised in the past but haven't got any answer.

My rebuild takes about 8-10 seconds for a minimal app, which simply has 2 basic components. This is quite frustrating. Furthermore, even the ng --help command is slow.
nv --version returns:
angular-cli: 1.0.0-beta.19-3 node: 6.9.1 os: win32 x64
I concur with previous comments that anything over 2 seconds really leads to contemplating alternative approaches. It would be great if this can be easily resolved, as the idea behind angular-cli is fantastic.

Yup, even ng version is slow for some reason, takes a few seconds. Maybe due to some file watcher thingy I don't know why it fires even for just checking the version.

ng version taking some time is due to some module discovery code going on. It's something we're looking at removing as well.

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 if any particular option has been missed.

@asadsahi So side-by-side, if you simply replace awesome-typescript-loader with ts-loader, what are the numbers like? What are the numbers like?

@intellix
With ts-loader:

With awesome-typescript-loader:

What does your node_modules/angular-cli/models/webpack-build-typescript.js look like. Did you have to change anything else?

@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. 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.

@asadsahi When will the fix for everyone?

@KhodeN I haven't tried in a project based on angular-cli. My above observation is from a non-cli based project.

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.

@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.

@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.

@filipesilva @clydin  I recently discovered issues with ts-loader regarding packages such as rxjs that have .js and .d.ts files next to each other (see https://github.com/TypeStrong/ts-loader/issues/347). Additionally it seems that there are no plans for ts-loader to support Webpack 2 (see https://github.com/TypeStrong/ts-loader/issues/283#issuecomment-248432016). As such it seems to me that awesome-typescript-loader is the best option currently. IMHO it's a shame that there is no officially supported, de facto TypeScript loader out there, but awesome-typescript-loader seems like the closest thing atm (and will become even more so once Webpack 2 is released).

@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.

@mischkl I didn't notice any issues using ts-loader in my playground project using Angular 2 (and RXJS obviously). It was a straight replacement with ATL.

How does one replace ATL with ts-loader? What files do I have to modify?

Even ng help also slow in my machine! ubuntu 14.04 86_64

Sadly, I'm considering buying a Mac Pro in order to be productive until this is fixed.

@rightisleft Mac pro won't solve this problem. Rather try to switch to the webpack version with no cli, what I did

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.

@asadsahi do you know what was done in 3.0.0 to speed things up?

@anton-107 Yes, its a non-cli project, but experiences presented here are of same nature.

Same problem here (x86_64 GNU/Linux system). I get a much faster rebuild time with the quickstart official repo

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 is --vendor-chunk same as generating DLL in webpack or different?

@asadsahi no, it is not using DLL, but I still want to look into it and compare to the vendor chunk.
It essentially uses CommonChunksPlugin to syphon every requests module from node_modules into a new chunk: https://github.com/angular/angular-cli/blob/master/packages/angular-cli/models/webpack-build-common.ts#L42-L48
It turned out to be one of the major performance increases because the chunk asset optimization step seems to operates over the whole chunk on reloads, and if we limit the changes to a chunk containing source files then it's much faster.

@filipesilva  Can we have exact metrics for considering this issue fixed? Something like "rebuild ames in less than 1 seconds" or soemthing like that.

I think there's a large performance regression in beta 22 in regards to SCSS compilation.
I did each of these in a single run and recorded times:
Saved styles: 11341, 10034, 10377, 9118, 10538
Saved HTML: 11820, 3224, 2820, 3002, 3983
Saved TS: 3982, 2701, 2561
Saved SCSS: 8856, 9551, 8793
Saved TS: 9505, 3888, 2961
As you can see, going from saving a SCSS to saving another file type (html or TS) causes that reload to also be slow once. If I look at the output, it spends a lot of time on SCSS files. I'm not doing anything intensive there.

Maybe this symlink improvement by  Microsoft could bring performance enhancements soon.

Enabling hot module replacement for sass gives a huge performance boost. As you don't have to wait for the page to reload every time. Would be cool to see that in place even if we can't get js HMR currently.

@mzvast I don't think the symlink improvement means anything for performance, it's just easier to do. @scottwio HMR is in beta.22, you can use it by providing the --hmr flag and following this project as an example: https://github.com/jschwarty/angularcli-hmr-example/ (just a few changes required)

Worth noting that --hmr is not a mainstream case though. Many people won't use it or won't be able to use it in their apps.
Not to mention people not using serve at all. At my current customer we are using build --watch because we are required to be as close as possible to our production which runs IIS, so we use this in local dev (and have some IIS modules running as well, etc).

Great, now using beta 22 with ng serve --no-sourcemap --hmr -e=dev-hmr with hmr config following https://github.com/jschwarty/angularcli-hmr-example/
Gives me acceptable timings, around 5 seconds from save to browser ready.

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.
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).

HMR drastically improves the time for the developer. 5 seconds means delay between hitting ctrl+s and page is ready in browser (including template compilation in the browser). Used to be more than 15 before beta 22.

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

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?

@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.

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

Experiment:
I made RAM disk and copy my project to it.
Build time is very small. For angular-cli beta 22 new project builds on 3-4 seconds and rebuilds when changed on 0.5-1.2 seconds. It is pretty cool.

@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! :(

With both beta21 and beta22, I have a 50sec build time with ng serve from the empty project. Also running ng -v takes 14sec.
Running on win10, both as normal user and as admin

If you would update to the latest one you'd see a massive improvement, I also had problems back in September with this but with the latest version I have +/- 2 secs compilation:
Time: 2394ms
chunk    {0} main.bundle.js, main.bundle.map (main) 137 kB {3} [initial]
chunk    {1} styles.bundle.js, styles.bundle.map (styles) 29 kB {4} [initial]
chunk    {2} scripts.bundle.js, scripts.bundle.map (scripts) 227 kB {4} [initial]
chunk    {3} vendor.bundle.js, vendor.bundle.map (vendor) 3.27 MB [initial]
chunk    {4} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]
webpack: bundle is now VALID.

I'm on latest already... beta.22

@hansl the metric I'll use is similar performance to a webpack2 project that is only using @ngtools/webpack plus the simplest possible optimizations (like vendor chunk or DLL). I'll get the baseline numbers and share them here, then aim at figuring out how our CLI setup affects them.
@simonech that's very odd, I've never seen that much delay. To be absolutely sure, can you try this please?
npm uninstall angular-cli -g
npm cache clean
npm install angular-cli -g
ng new test-proj
cd test-proj
ng build # check build time here
ng serve # check serve time here

Can you also tell me your system specs, and anything else you think is relevant about your system?

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.

Nice work @filipesilva . I am really counting on DLL implementation, I believe many of us will be amazed how quick rebuild can be with dll. I have seen 200-300ms rebuilds in a medium sized project.
Also, Thumbs up for dynamically creating list of dll bundle.

@filipesilva
Did some tests, and I realized I was on power saving mode. But still with high performance settings build takes 23sec and serve takes 30sec. Feels too much anyway
Systems specs:
Microsoft Surface Pro
Intel Core i5-3317U @ 1.70 GHz
RAM 4Gb
SSD 128Gb
Windows 10
Space available on the disk is not much, just a few Gb
Install went fine, only warning I got was
npm WARN optional Skipping failed optional dependency /angular-cli/chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture<EMAIL_ADDRESS>
ng new took 65sec till it said Installing packages for tooling via npm. and 6:30" for completing the npm install
ng build: 1:05"... 17" till the first message appeared, 49sec build time as reported in the output
ng serve: 1:12" with a stop watch: 17" secs till first message, 55sec as reported in the output
Also ng -v takes 13" sec
angular-cli: 1.0.0-beta.24
node: 6.9.1
os: win32 x64
@angular/common: 2.4.0
@angular/compiler: 2.4.0
@angular/core: 2.4.0
@angular/forms: 2.4.0
@angular/http: 2.4.0
@angular/platform-browser: 2.4.0
@angular/platform-browser-dynamic: 2.4.0
@angular/router: 3.4.0
@angular/compiler-cli: 2.4.0

Here how power settings affect the build time.
Running as admin doesn't affect much

Power saving:

ng build: 17 sec initial lag, 49sec build, 1:05 overall
ng serve
ng -v: 13sec

Balanced:

ng build: 7sec initial lag, 18sec build time, 25sec overall
ng serve: 7sec initial lag, 18sec build time, 25sec overall
ng -v:  5 sec

High perf:

ng build: 5sec initial lag, 17sec build time, 23sec overall
ng serve: 6sec initial lag, 22sec build time, 30sec overall
ng -v: 5 sec

@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

Yeah, but the 5-6 sec for just ng -v should not be affected by av or disk, right?
Will try from a beefier machine tomorrow and see.
Thx
Sent from my iPad

On 21 Dec 2016, at 22:56, Filipe Silva<EMAIL_ADDRESS>wrote:
@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
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Part of the ember-cli addon discovery code does walk node deps to see if there are addons there, so it disk speed would affect it. I'd never expect it to take more than 3 seconds on HDD evens though. It's something we want to remove though.

@filipesilva ng -v on my window 10 machine takes around 25-26 seconds to display version no.
With HMR, First load takes ~30 secconds and rebuild time on same machine 12-13 seconds.

@simonech @asadsahi can you do me a favor and try this to see build time?
git clone https://github.com/filipesilva/angular-cli-benchmark-app
cd angular-cli-benchmark-app
npm install
npm start

Then copying ./src/ onto a ng new project and see the ng build time there as well.
My point in asking this is to see if there is a vast difference between running the webpack compilation from within the CLI or from a barebones project.
I tested this in my machine and the CLI was faster, but I begin to wonder if there is something that is slowing down other setups.

@filipesilva
angular-cli-benchmark-app build times:

new angular-cli project build times before overriting angular-cli-benchmark-app src:

After overtiring angular-cli-benchmark-app src > new angular-cli project:

Not sure why getting require doesn't exist in app.component.ts as there is no require statement, but I guess, build times can be seen even with this error.

@asadsahi thank you for the time you took to put these together.
The missing require is relevant somewhat. Mostly because it was something that would only happen in older versions of the CLI. That together with the fact that you're not getting an auto-generated vendor bundle makes me think the generated project is actually on beta.19 or beta.20.
Can you confirm what version you used for that test please? beta.22 and above brought many improvements to the build speed. A lot of the time in your screenshot is being spent on building modules, and if I remember correctly that was an issue related to awesome-typescript-loader (which we then switched to @ngtools/webpack).
If you have the time, I would appreciate those two tests repeated with beta.24. You shouldn't need to update your global version, it should be enough to update the local project one.

@filipesilva sorry, installation of beta 24 didn't happen correctly, Beta 20 stuck on windows 10 even after cleaning cache. So I have to manually delete angular-cli folders and did beta 24 installs globallay and created new projects from scratch. I can confirm new tests are from beta 24.
I have updated above screenshots with new tests. Let me know if you need any more information.
Thanks

@filipesilva Did some tests with your benchmark repo on my system. The results are:
For the angular-cli-benchmark-app:
Hash: 65007cd0b108b0cabe02
Version: webpack 2.1.0-beta.25
Time: 7634ms
               Asset       Size  Chunks             Chunk Names
     0.bundle.js.map     111 kB       0  [emitted]
         0.bundle.js     107 kB       0  [emitted]
         2.bundle.js    2.46 kB       2  [emitted]
      main.bundle.js    6.06 kB       3  [emitted]  main
    vendor.bundle.js     2.8 MB       4  [emitted]  vendor
         1.bundle.js     107 kB       1  [emitted]
     1.bundle.js.map     111 kB       1  [emitted]
     2.bundle.js.map    1.02 kB       2  [emitted]
  main.bundle.js.map    3.67 kB       3  [emitted]  main
vendor.bundle.js.map       3 MB       4  [emitted]  vendor
          index.html  402 bytes          [emitted]

For the angular-cli generated project:
Hash: c6e22cffdebd68f501db
Time: 8578ms
chunk    {0} 0.chunk.js, 0.bundle.map 87 kB {3} {2} {1} [rendered]
chunk    {1} 1.chunk.js, 1.bundle.map 86.9 kB {2} {0} {3} [rendered]
chunk    {2} 2.chunk.js, 2.bundle.map 1.76 kB {0} {1} {3} [rendered]
chunk    {3} main.bundle.js, main.bundle.map (main) 3.9 kB {5} [initial] [rendered]
chunk    {4} styles.bundle.css, styles.bundle.map, styles.bundle.map (styles) 1.77 kB {6} [initial] [rendered]
chunk    {5} vendor.bundle.js, vendor.bundle.map (vendor) 2.36 MB [initial] [rendered]
chunk    {6} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry] [rendered]

My system is Ubuntu 14.04.

@asadsahi awesome, thanks for the update! So your numbers clearly show an increase from 15ish secs on a webpack project to 19secs on a CLI project.
I picked the last (and best) build time for the CLI because I know it has some kind of warm up time that I think is node related. After a brand new install the first few builds are slower but then it stabilises. For instance, your numbers went from 27secs to 19secs on a operation that does not keep state (ng build).
It still is roughly 3~4 times bigger than the numbers I get. To me that says that there is a system resource being heavily stressed on your system, and that resource is being used more by the CLI than on a bare webpack config.
I will investigate on that premise. I suspect either disk access or CPU, and will see which extra webpack plugins are mostly impacting those.

System Specs:
i5 4460 Quad Core
16GB RAM
Windows 10
My Results:
Webpack Benchmark App:

Angular CLI Beta 24:

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

@filipesilva I ran ng build and ng serve from a standard npm install, on a much more powerful machine (Win10 i7-3770 3.7ghz with 8GB RAM and SSD), and for both I had 8sec build time

@filipesilva tested the two benchmarks
web-pack: 6529, 6311

ng build (using beta24 --progress=false) 6874,6786

I'll try it again this evening on the slower machine

As mentioned in #3203, asset optimization seems to be still one area to check, especially when you start having a few images in assets (or, worse, in my case some binary .dll files -that's totally NOT Webpack DLLs- used for IIS auth and stuff, generated from bigger project).
It takes several seconds, and it seems to be running in partial / incremental builds (watch mode) not just initial build.
Might be possible to disable in dev?

Specs:
Windows 10 x64 Build 1607
Intel Core 2 Duo E7600 (Yep, not even full 64-bit support)
8GB Ram
Samsung 850 Pro SSD

@filipesilva
I ran the test again on my low-spec Microsoft Surface Pro
the webpack build was 10694, 10258 (but overall time has the usual 5 secs lag)

Running CLI build --progress=false: 12285,11291 (with high perf power settings)

So both on my Surface Pro and on my work machine i7, running directly webpack is slightly faster than CLI (200-300ms - 5-ish% on the fast machine, 1-1.5sec 10-ish% on the slower Surface Pro)
HTH and let me know if you want me to run other tests/benchmarks

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.

@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.

@filipesilva https://github.com/angular/angular-cli/issues/1980#issuecomment-268592049

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 think there is nothing wrong by manually listing all vendor package names in an array. I dont see any other solution how this can be automatically done. Take a look at this config file https://github.com/qdouble/angular-webpack2-starter/blob/master/constants.js#L65-L69 and on the project in general.

https://github.com/angular/angular-cli/pull/3805 should help with the initial command startup time. In my tests it was reduced by 50%, but since running from master also compiles the CLI's TS files on the fly, the reduction might be more dramatic after a release.

npm ls --depth=0 --production
+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>`--<EMAIL_ADDRESS>
from this you can get the polyfill and library list you include over npm
with npm postinstall hook you create the new dll build and make it automatic
also make it available over cli, ng build:dll to trigger it manually if need

I think there are too many special cases to allow an automatic dll build to be ultimately reliable (e.g., including all depth zero packages would include packages that are not used in code; which could be benign or fatal).
Realistically, is it even necessary?  The dll build is only really useful in development scenarios (ng serve / ng build --watch) as the vendor bundle covers production builds.  So providing maximum configurability may not be needed.   Covering the known large code size offenders (i.e., the angular libraries and their dependencies) should hopefully provide a noticeable performance improvement with minimal additional complexity.  Further, the configurability can always be expanded upon in the future.

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 brake as soon as an angular lib is factored out into the DLL bundle.

Another update: moving to<EMAIL_ADDRESS>(https://github.com/angular/angular-cli/pull/3786) seems to have had roughly a 30% performance (1.69s to 1.3s) increase in rebuilds.

+1 for improving the speed at least for scss and ts compilation. Compared to Gulp it takes 10sec on my machine compiling Bootstrap SCSS  instead of less than 500ms. Smiliar results on ts files.

@MickL are you seeing similar results to my comment? https://github.com/angular/angular-cli/issues/1980#issuecomment-264649140
I think my comment about saving SCSS files went unnoticed and it's insane :)

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

Does angular-cli offer live-reload feature?
If so, what makes the difference as compared to react?
My react project applies code changes instantly whether it is js or styles...
I assume it's using webpack-hot-middleware.
I'm going to use this starter kit, wondering how it affects development speed.

@RumenTech modifying scss files trigger recompilation. Cold start of my project is 25 seconds, while small change in scss file takes ~2-4 seconds BUT app is being refreshed.

This is what I'm dealing with on one of my larger projects that uses .scss, and ng build -prod -aot
Time: 678933ms // 11 minutes

I guess TypeScript compiler is okay. But SCSS is far too slow. As far as i know Angular CLI is using libsass which is the best choice. But lets compare a regular Boostrap compile with gulp-sass in combination with gulp-sourcemaps.
On my machine(latest 27" iMac) i get following results in average:
Gulp: 250ms
Angular CLI: 4500ms
Also we have a full page reload instead of just reloading the styles. But this is not part of this issue i guess.
Steps to reproduce:

ng new sassy-project --style=sass
npm install<EMAIL_ADDRESS>--save-dev
Add import to /src/app/style.scss: @import '../node_modules/bootstrap/scss/bootstrap';
ng serve
Try adding something into styles.scss, for example: h1 { color:red; }
Reload takes 4-5s on my machine

In my env (ng beta-24), 8GB RAM, SSD, Ubuntu VirtualBox on Windows 10 it takes also a minute to rebuild. Does anyone know a good article describing an alternative build/serve process, while maintaining the structure provided by angular-cli, so I could come back when the issue is resolved ?
Thanks so much.

@ralf100  i think the angular-cli is mainly only about to have entry point, src folder, assets folder and angular-cli so you can have some better starte pack (i strongly suggest you that one from QDOUBLE on github) and still use Angular-cli for scaffolding, then you shoudl be able to switch back.

Time: 15111ms
Around 15s for a project I just recently started with, so not too big yet.
I'm on Windows7, npm v.4.1.1, node v6.9.2
<EMAIL_ADDRESS>

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

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?

@hccampos awesome deduction, what does it look like with CSS preproccesors?

Hey @hccampos, thanks for those! Very helpful.
So I feel you're running a ng build, correct? I ran a ng serve (with https://github.com/angular/angular-cli/pull/3961 locally) and modified a file a bunch of times, and I got a very different graph:

Here's the cpuprofile file:
test.cpuprofile.zip
@TheLarkInn seems like the above a lot of the time is lost in ReplaceSource and HarmonyModulesHelpers.

Sorry the screen above is sorted by Total Time. Here's sorted by Self Time:

Seems like Typescript does a lot of checks. Let's see if we can help there.

@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 (;

Yes, isolatedModules are good when you know you are not messing about with
imports. However, you lose the checks against other files if you do change
imports. My point is it should be possible in to keep track of which
imports changed and then only check those.
Hard problem though, especially when combining TS with Webpack.
On Jan 12, 2017 07:17, "Aleksandar Milošević"<EMAIL_ADDRESS>wrote:
@hansl https://github.com/hansl @hccampos https://github.com/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 (;
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/1980#issuecomment-272085546,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADlcCt6N92TzYrtLLdmJllmbr5PlB97Sks5rRcVrgaJpZM4J07P9
.

@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...

@sasxa Good point indeed! Still would be nice if TS and Webpack could optimize further since it would be a gain for everyone, both those who use TS aware editors and those who don't. In Webpack's case, it would be great also for people using React and other non-ts stuff.

Not sure if this is helpful at all but I noticed that build and rebuild of the exact same project are an order of magnitude faster on my machine when running osx rather than windows 10. I'm on a new macbook pro (i7-6820 / 16gb) and build/rebuild is around 8,000ms / 2,500ms under osx, but 45,000/10,000ms under Windows 10 (bootcamp, not virtualized).  I'm on beta.24 currently, and this is a real application, not huge, but significantly more than hello world. 2,5s rebuild is acceptable for workflow IMO, 10s is painful.
Any further information I can provide that might be useful?

@mrlund can you try adding your project folder as an exclusion to Windows Defender, to see if it helps?
https://support.microsoft.com/en-ie/instantanswers/64495205-6ddb-4da1-8534-1aeaf64c0af8/add-an-exclusion-to-windows-defender

OS X is an outlier in this case, and we have file system events to thank
for that. No constant check of modification dates, just an event that gets
emitted whenever a file changes that the driver can act on. Don't be fooled
by the time difference.
On Thu, Jan 12, 2017 at 7:38 AM Filipe Silva<EMAIL_ADDRESS>wrote:

@mrlund https://github.com/mrlund can you try adding your project
folder as an exclusion to Windows Defender, to see if it helps?
https://support.microsoft.com/en-ie/instantanswers/64495205-6ddb-4da1-8534-1aeaf64c0af8/add-an-exclusion-to-windows-defender
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/1980#issuecomment-272153139,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADajDVajAsG8Tb9HIHRo8Y40yn3SkQunks5rRh7WgaJpZM4J07P9
.

@filipesilva No discernible difference with project folder excluded in Windows Defender.

@gelliott181 @mrlund I don't notice a difference in my system either but wanted to double check. It seems to help for Ember projects but we've since moved away from brocolli.

Have you experimented with this before? parallel-webpack.
I just learned about it from here in this awesome deck Addy Osmani recommended about Webpack.

I think that one would be tricky to add. There is also Happypack, but it doesn't (and likely never will) play well wit h typescript.
Hopefully we can make some more profiles with the new profiling options and then find places where the cli, webpack and TS can improve. I haven't had the time to dig more into it, but hopefully will soon.

Here you go @hansl and @TheLarkInn , a profile of 3 rebuilds without any changes to any files (only pressing cmd+s in VSCode to trigger a rebuild).
CPU-20170116T224647.cpuprofile.zip
This thing here looks suspicious, the Angular compiler doing a LOT of stuff there. But I am not familiar with it at all.

Just to add another experience Report: I've switched to working on my Project on a Windows machine recently (from OS X) and even though my new machine is significantly faster running our full AOT builds (120s down to 75s), rebuilds are taking much longer (2.5s to 16s).
I can thus certainly confirm what @mrlund reported.

@mrlund @JohannesRudolph I work on a windows machine but don't get that massive slowness. Mine is win10, and I have an admin account.
Can you give me your system specs and whether or not you have admin? Maybe I can figure out how to repro it on my machine.

@filipesilva: it's a fresh install of win10 pro, I'm admin (local user account) and it's a<EMAIL_ADDRESS>SSD, 16GB RAM....
The slowdown on Windows compared to OS X (exact same repo etc.) is very interesting indeed. Let me know if there's anything I can help you with to get to the bottom of this.

From looking at the Task Manager during a live rebuild I get the impression that it's not an i/o bound issue, thus pointing away from fsevents and friends. Though that may be misleading due to fs caching in the OS.
Disk active time stays below 2% while one CPU core is fully loaded (indicating webpack is single-threaded at the moment). So whatever it is, the Windows rebuild appears does a lot more work than a rebuild on OS X

@filipesilva My experience is the same as @JohannesRudolph I'm on a new touchbar MacBook Pro 15", a i7-6820HQ @ 2.7GHz with 16GB RAM, and the super-fast SSD.
I'm NOT using SCSS, but plain CSS, and I get similar numbers, that indicate the hardware is by no means stressed (8-9% CPU, 0-5% Disk) during both build and rebuild. One notable thing, however is that the node process reaches almost 1GB of RAM consumption, which seems excessive?
Windows 10 (x64), recent install, node 6.9.4. (was previously running node 7), local admin user. I've also run ng serve from an elevated command prompt as the actual admin user with no discernable difference.

@JohannesRudolph can you try making a new project using plain CSS and another with SCSS on your machine to see if the rebuild differences are noticeable?

@mrlund could you check if you also get it on a new project? I'm wondering if it's project specific.
Also could you tell me the path your slow project is at? And if you have any symlinked node modules.

@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

@montella1507 i experience the same issue. On ubuntu 16.04 rebuild time is ... managable, on windows 10 it is a real pain.

This is from testing two fresh ng-init projects:
angular-cli: 1.0.0-beta.26
node: 7.3.0
os: win32 x64

CSS:
PS C:\dev\ng-css> npm run start

><EMAIL_ADDRESS>start C:\dev\ng-css
> ng serve

** NG Live Development Server is running on http://localhost:4200. **
Hash: 164111cf5cd94c55d065
Time: 6537ms
chunk    {0} main.bundle.js, main.bundle.map (main) 4.52 kB {2} [initial] [rendered]
chunk    {1} styles.bundle.js, styles.bundle.map (styles) 9.96 kB {3} [initial] [rendered]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.84 MB [initial] [rendered]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry] [rendered]
webpack: bundle is now VALID.

=> Rebuild (change app.component.ts)
webpack: bundle is now INVALID.
Hash: 164111cf5cd94c55d065
Time: 2265ms
chunk    {0} main.bundle.js, main.bundle.map (main) 4.52 kB {2} [initial]
chunk    {1} styles.bundle.js, styles.bundle.map (styles) 9.96 kB {3} [initial]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.84 MB [initial]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]
webpack: bundle is now VALID.

SCSS:
PS C:\dev\ng-scss> npm run start

><EMAIL_ADDRESS>start C:\dev\ng-scss
> ng serve

** NG Live Development Server is running on http://localhost:4200. **
Hash: 5585be96c8aac1577ee8
Time: 5230ms
chunk    {0} main.bundle.js, main.bundle.map (main) 4.53 kB {2} [initial] [rendered]
chunk    {1} styles.bundle.js, styles.bundle.map (styles) 10.1 kB {3} [initial] [rendered]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.84 MB [initial] [rendered]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry] [rendered]
webpack: bundle is now VALID.

=> Rebuild (change app.component.ts)

webpack: bundle is now INVALID.
Hash: 5585be96c8aac1577ee8
Time: 1133ms
chunk    {0} main.bundle.js, main.bundle.map (main) 4.53 kB {2} [initial]
chunk    {1} styles.bundle.js, styles.bundle.map (styles) 10.1 kB {3} [initial]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.84 MB [initial]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]

Rebuild times with these seem fine. For my large project, I have also tried uninstalling and re-adding angular-cli via yarn (to force transient dependency upgrade to latest version) without a change in rebuild times on windows.

@montella1507 how do you reach that conclusion? Rebuilds do not appear to stress my disk at all (<2% active time according to task manager).

@filipesilva I think I have to retract my earlier reported OS-X 2.5s vs Windows 16s numbers for rebuild time. Turns out the Windows build had ng serve --aot=true and OS X had ng serve --aot=false which easily explains the difference. With --aot=true my mac builds at 24s, which matches the speed difference I expect between the machines based on running a full ng build --aot=true.... sorry for all the fuss.

@JohannesRudolph  well... because NTFS system is not optimized to work with 100 000 small files.. Try to remove node_modules folder on windows and on linux...  Its like 120sec and 2sec.
I have tried to build our application on both linux and windows with same HW. Linux is 4times faster +-.

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

@filipesilva Yea, I tried adding it manually too, and failed miserably. I think a big cause of bad rebuild performance in large projects is the project structure itself. That is, whether you use barrels or not, whether you re-export things a lot, whether you have large modules, whether you add typings to all the variables, etc.
Unfortunately, though, I haven't been able to really determine what the best practices are to keep rebuild times low. One thing we try doing is adding types to most things so TS doesn't have to spend so much time inferring stuff, but with observables it is a PITA to do. So far not much has worked.
Do you guys have an idea of what those best practices are?

@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 massive. And both projects have lazy routes there too.
Do we know what sort of challanges we are having with lazy routes?

@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 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.

@filipesilva With an unmodified new project I'm seeing better perf, though I guess that's obvious. Considering the simplicity, not blistering, however:  16s build / 4,5s rebuild.
My path is C:\Users<user>\Source\Repos\perftest, and no symlinked node modules.

@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

This was merged to master, so should show up in next npm release in a couple of days, correct? I'd prefer not to link master unless it's important.

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

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.

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

The rebuild performance has been vastly improved but it hasn't been released yet :) You'll see improvements when master is tagged.
After the stuff that's in master, the DLL only gave an additional 5% or so but there were issues with lazy-loading which can't be fixed until the way lazy-loading is done in Angular changes. Unless you managed it with ng-x-cli? I think @filipesilva has more details

@intellix: When will the next release be? The current master is producing errors for me (Cannot find module '@ngtools/json-schema').

@intellix ahh, i no longer use the master branch

there were issues with lazy-loading which can't be fixed until the way lazy-loading is done in Angular changes. Unless you managed it with ng-x-cli? I think @filipesilva has more details

Good idea, TBH i didnt run any benchmark / gave it any extra thought because the rebuilding time on my sucky laptop (os: win 10) was blazing fast.
Btw ng-x-cli is just a mix of: qdouble/angular-webpack2-starter's minimal branch and some features from angular-cli. Namely these features are:

Global styles
Build Targets and Environment Files
Project assets

I also took the naming of different config keys ng-cli.config.js from angular-cli.json so i can transition back to angular-cli without any complications.

Try 28 guys. I've just compared my large project before and after and it's so much faster than 40% as advertised.
Before with b26: 3.3sec average on save
Now with b28.3: 1sec average on save

On windows, performance boost is even more significant, as not to say astronomic:
My rebuild times:
beta26: around 15s..
beta28: under 1s-2s. (!)
Really great job, guys!

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.

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

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.

Great job!
From 2s-4s time to 300-600ms

Massive improvement for me on Windows 10
beta26: ~12s
beta28: ~2s
Thanks!

While it's better with the new cli, here it is...
webpack: bundle is now VALID.
webpack: bundle is now INVALID.
Hash: 4e3ed080d33362fa5a97
Time: 14510ms
chunk    {0} 0.chunk.js, 0.bundle.map 2.82 MB {1} {2} {3} {4} {6} [rendered]
chunk    {1} 1.chunk.js, 1.bundle.map 2.81 MB {0} {2} {3} {4} {6} [rendered]
chunk    {2} 2.chunk.js, 2.bundle.map 2.24 MB {0} {1} {3} {4} {6} [rendered]
chunk    {3} 3.chunk.js, 3.bundle.map 2.66 MB {0} {1} {2} {4} {6} [rendered]
chunk    {4} 4.chunk.js, 4.bundle.map 1.32 MB {0} {1} {2} {3} {6}
chunk    {5} polyfills.bundle.js, polyfills.bundle.map (polyfills) 418 kB {9} [initial]
chunk    {6} main.bundle.js, main.bundle.map (main) 143 kB {8} [initial] [rendered]
chunk    {7} styles.bundle.js, styles.bundle.map (styles) 412 kB {9} [initial]
chunk    {8} vendor.bundle.js, vendor.bundle.map (vendor) 4.72 MB [initial]
chunk    {9} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]
webpack: bundle is now VALID.
webpack: bundle is now INVALID.
Hash: 4e3ed080d33362fa5a97
Time: 6314ms
chunk    {0} 0.chunk.js, 0.bundle.map 2.82 MB {1} {2} {3} {4} {6}
chunk    {1} 1.chunk.js, 1.bundle.map 2.81 MB {0} {2} {3} {4} {6}
chunk    {2} 2.chunk.js, 2.bundle.map 2.24 MB {0} {1} {3} {4} {6}
chunk    {3} 3.chunk.js, 3.bundle.map 2.66 MB {0} {1} {2} {4} {6}
chunk    {4} 4.chunk.js, 4.bundle.map 1.32 MB {0} {1} {2} {3} {6}
chunk    {5} polyfills.bundle.js, polyfills.bundle.map (polyfills) 418 kB {9} [initial]
chunk    {6} main.bundle.js, main.bundle.map (main) 143 kB {8} [initial]
chunk    {7} styles.bundle.js, styles.bundle.map (styles) 412 kB {9} [initial]
chunk    {8} vendor.bundle.js, vendor.bundle.map (vendor) 4.72 MB [initial]
chunk    {9} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]
webpack: bundle is now VALID.
webpack: bundle is now INVALID.
Hash: 4e3ed080d33362fa5a97
Time: 5401ms
chunk    {0} 0.chunk.js, 0.bundle.map 2.82 MB {1} {2} {3} {4} {6}
chunk    {1} 1.chunk.js, 1.bundle.map 2.81 MB {0} {2} {3} {4} {6}
chunk    {2} 2.chunk.js, 2.bundle.map 2.24 MB {0} {1} {3} {4} {6}
chunk    {3} 3.chunk.js, 3.bundle.map 2.66 MB {0} {1} {2} {4} {6}
chunk    {4} 4.chunk.js, 4.bundle.map 1.32 MB {0} {1} {2} {3} {6}
chunk    {5} polyfills.bundle.js, polyfills.bundle.map (polyfills) 418 kB {9} [initial]
chunk    {6} main.bundle.js, main.bundle.map (main) 143 kB {8} [initial]
chunk    {7} styles.bundle.js, styles.bundle.map (styles) 412 kB {9} [initial]
chunk    {8} vendor.bundle.js, vendor.bundle.map (vendor) 4.72 MB [initial]
chunk    {9} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]
webpack: bundle is now VALID.
webpack: bundle is now INVALID.
Hash: 4e3ed080d33362fa5a97
Time: 5380ms
chunk    {0} 0.chunk.js, 0.bundle.map 2.82 MB {1} {2} {3} {4} {6}
chunk    {1} 1.chunk.js, 1.bundle.map 2.81 MB {0} {2} {3} {4} {6}
chunk    {2} 2.chunk.js, 2.bundle.map 2.24 MB {0} {1} {3} {4} {6}
chunk    {3} 3.chunk.js, 3.bundle.map 2.66 MB {0} {1} {2} {4} {6}
chunk    {4} 4.chunk.js, 4.bundle.map 1.32 MB {0} {1} {2} {3} {6}
chunk    {5} polyfills.bundle.js, polyfills.bundle.map (polyfills) 418 kB {9} [initial]
chunk    {6} main.bundle.js, main.bundle.map (main) 143 kB {8} [initial]
chunk    {7} styles.bundle.js, styles.bundle.map (styles) 412 kB {9} [initial]
chunk    {8} vendor.bundle.js, vendor.bundle.map (vendor) 4.72 MB [initial]
chunk    {9} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]
webpack: bundle is now VALID.

First run is with a single line change, the others are without any changes at all. With https://github.com/AngularClass/angular2-webpack-starter the time goes to 1s (sometimes less), since it uses the DLLplugin (my guess as to the reason). Unfortunately we can't easily switch over because we are making heavy use of the cli's environments and testing setup, and it would be better to use the "official" setup.
Anyway, we might be sort of a special case since we are loading most of RxJS, ThreeJS, Openlayers, D3, crypto-js, lodash, turf and a bunch more.

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 would also be remiss without giving serious kudos to the team.  Huge thanks all!

Totally agree with John. Great work! Thanks.
On Mon, Mar 6, 2017 at 1:52 AM, John Livingston<EMAIL_ADDRESS>wrote:

I would also be remiss without giving serious kudos to the team.  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

We aim to please 😄

I'm seeing 40-60 second build times with rc4, thought this was normal...

@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.

Rebuild. The original build is a little longer. I've seen it as low as 46, but just then it was 88:
Imgur
I'll try enabling source maps only if I'm doing some serious debugging. Thanks.

@hanvyj What's your command line look like?

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\"",

That explains it.

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 @Injectable(), no idea how that worked with AoT on!).

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?

@cyberprodigy please open a separate issue including the information from the template so that we can fully assist you.  Please also be sure that you are using the latest version (1.0.0 at this time).
Thank you.

@cyberprodigy it takes like 1 second on my machine with latest cli. You may dont have the latest installed.

I upgraded a project from<EMAIL_ADDRESS>to 4.0.0 ( "@angular/cli": "1.0.0") and unfortunately don't see much improvements
here is stat from new cli:
><EMAIL_ADDRESS>start /projects/ctc/5390-promo/promo-client
> ng serve --host <IP_ADDRESS> --port 5555 --proxy-config proxy.conf.json -o

** NG Live Development Server is running on http://<IP_ADDRESS>:5555 **
 11% building modules 15/26 modules 11 active ...ode_modules/style-loader/addStyles.jswebpack: wait until bundHash: 4c427ff407b3e5292822

Time: 27387ms

chunk    {0} main.bundle.js, main.bundle.js.map (main) 1 MB {3} [initial] [rendered]
chunk    {1} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 158 kB {4} [initial] [rendered]
chunk    {2} styles.bundle.js, styles.bundle.js.map (styles) 295 kB {4} [initial] [rendered]
chunk    {3} vendor.bundle.js, vendor.bundle.js.map (vendor) 5.26 MB [initial] [rendered]
chunk    {4} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]
webpack: Compiled successfully.

and here is from old one:
><EMAIL_ADDRESS>start /Users/juliapassynkova/ctc/projects/5390-promo/promo-client
> ng serve --host <IP_ADDRESS> --port 5555 --proxy-config proxy.conf.json -o

** NG Live Development Server is running on http://<IP_ADDRESS>:5555. **                                                  10% building modules 3/3 modules 0 active[HPM] Proxy created: /api  ->  http://localhost:8080/promo
[HPM] Proxy created: /oauth  ->  http://localhost:8080/promo                                                   11% building modules 15/27 modules 12 active ...odules/bootstrap/dist/js/bootstrap.jswebpack: wait until bundle finished: /                                                                         11% building modules 16/30 modules 14 active ...s/webpack-dev-server/client/socket.js(node:6412) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https://github.com/webpack/loader-utils/issues/56
parseQuery() will be replaced with getOptions() in the next major version of loader-utils.             22872ms building modules                              5ms add04223ms 131ms asse116ms emitting
Hash: 8531c2e494bb70e33827
Version: webpack 2.1.0-beta.25

Time: 29684ms
                                 Asset       Size  Chunks             Chunk Names
 fee66e712a8a08eef5805a46892932ad.woff      98 kB          [emitted]
  bce071e976865da511003c50333620c5.eot    2.52 kB          [emitted]
  b0aebd744ce7adb780a9342fd395535e.svg    2.67 kB          [emitted]
<PHONE_NUMBER>7bd7575d6327160d64e760.svg     109 kB          [emitted]
  674f50d287a8c48dc19ba404d20fe713.eot     166 kB          [emitted]
  912ec66d7572ff821749319396470bde.svg     444 kB          [emitted]
  e18bbf611f2a2e43afc071aa2f4e1512.ttf    45.4 kB          [emitted]
 fa2772327f55d8198301fdb8bcfc8158.woff    23.4 kB          [emitted]
448c34a56d699c29117adc64c43affeb.woff2      18 kB          [emitted]
  b06871f281fee6b241d60582ae9369b9.ttf     166 kB          [emitted]
af7ae505a9eed503f8b8e6982036873e.woff2    77.2 kB          [emitted]
  f4769f9bdb7466be65088239c12046d1.eot    20.1 kB          [emitted]
  d329cc8b34667f114a95422aaad1b063.ttf     162 kB          [emitted]
  ac3f799d5bbaf5196fab15ab8de8431c.ttf     163 kB          [emitted]
                        main.bundle.js    7.46 MB    0, 3  [emitted]  main
                      styles.bundle.js     295 kB    1, 3  [emitted]  styles
                     scripts.bundle.js     376 kB    2, 3  [emitted]  scripts
                      inline.bundle.js    5.53 kB       3  [emitted]  inline
                              main.map     7.9 MB    0, 3  [emitted]  main
                            styles.map     397 kB    1, 3  [emitted]  styles
                           scripts.map     462 kB    2, 3  [emitted]  scripts
                            inline.map     5.6 kB       3  [emitted]  inline
                            index.html  783 bytes          [emitted]
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  3.17 kB       0
webpack: Compiled successfully.
[default] Checking started in a separate process...
[default] Ok, 2.852 sec.

@cyberprodigy - If you are running it locally for development purposes, you should be using "ng serve", not "ng build".

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 /node_modules) 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

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

What @clydin said, basically. Build times will not improve much (although webpack itself is reporting improvements so we shall see); rebuilding time should be much faster. Keep your process running and you'll see improvements.
Locking this conversation down. This issue has been resolved a long time ago.


Move getting started and migration guides to main repo

PR to keycloak: https://github.com/keycloak/keycloak/pull/16675
Do not merge until above is merged, and available in a Keycloak release
Closes #16575

I reviewed the changes, and found the following problems:

The Links.java is missing updated links to the repositories for the migration and getting started guides, so that the "Edit this page" points to the right place.

            case MIGRATION:
                return "https://github.com/keycloak/keycloak/tree/main/docs/guides/src/main/migration/" + guide.getName() + ".adoc";
            case GETTING_STARTED:
                return "https://github.com/keycloak/keycloak/tree/main/docs/guides/src/main/getting-started/" + guide.getName() + ".adoc";

When building this site, the guide-vue.html prints warnings, that the two includes are not found. Looking at the page, it shows "Unresolved directive in  - include::../includes/getting-started/start-keycloak-localhost.adoc[]"
The images shown on the guide-vue.html are broken

I didn't see an obvious solution for the last two items, so I ask you to have a look. Thanks!

I've fixed the links, and did a quick fix for the Vue guide. The last one is probably something we need to remove or rework anyways as it's rather old and not maintained.