stellasoft-george
commented
8 years ago +1 Rebuilds are extremely slow for me on OSX 10.11.6
Closed asadsahi closed 7 years ago
stellasoft-george
commented
8 years ago +1 Rebuilds are extremely slow for me on OSX 10.11.6
RicardoVaranda
commented
8 years ago +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.
filipesilva
commented
8 years ago @TheLarkInn can you weigh in? It seems related with CopyWebpackPlugin.
ghost
commented
8 years ago 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.
intellix
commented
8 years ago Would DLL loading for vendor items help here? They must be 90% of bundle size
dasAnderl
commented
8 years ago +1 build/rebuilds extremely slow, as well as the update/recompiling in the browser. as well as ng test
guiomie
commented
8 years ago +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 
thorsten
commented
8 years ago Same issue here.
filipesilva
commented
8 years ago https://github.com/angular/angular-cli/pull/2570 moved away from CopyWebpackPlugin to a simpler glob copy. This should help with @RicardoVaranda's issue.
filipesilva
commented
8 years ago @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.
sasxa
commented
8 years ago @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?
guiomie
commented
8 years ago 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?
filipesilva
commented
8 years ago @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.
asadsahi
commented
8 years ago @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.
ipassynk
commented
8 years ago 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 emittingng version:
angular-cli: 1.0.0-beta.16
node: 4.5.0
os: darwin x64
mhadaily
commented
8 years ago same here , it's too slow!
angular-cli: 1.0.0-beta.17
node: 6.6.0
os: darwin x64
Version: webpack 2.1.0-beta.25
Time: 8100ms
Asset Size Chunks Chunk Names
main.bundle.js 3.12 MB 0, 2 [emitted] main
styles.bundle.js 10.2 kB 1, 2 [emitted] styles
inline.js 5.53 kB 2 [emitted] inline
main.map 3.19 MB 0, 2 [emitted] main
styles.map 14.2 kB 1, 2 [emitted] styles
inline.map 5.59 kB 2 [emitted] inline
index.html 480 bytes [emitted]
assets/.npmignore 0 bytes [emitted]
Child html-webpack-plugin for "index.html":
Asset Size Chunks Chunk Names
index.html 2.81 kB 0
webpack: bundle is now VALID.
JanStureNielsen
commented
8 years ago See #2651
clydin
commented
8 years ago @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.
guiomie
commented
8 years ago Should this be bumped as critical? It seems to impede peoples productivity and maybe scare new comers to angular-cli.
JohannesRudolph
commented
8 years ago to chime in here with some data of a fairly small angular2 project using scss:
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 The most time is spent on chunk asset optimization, so that looks like a worthwhile target.
intellix
commented
8 years ago Running ng test is excruciatingly slow. It takes quite some time to detect there are changes and then re-run them.
New project with 79 tests:
Single/first run: ~90s Changes:: ~12s Changes after using for some time before it crashes:: ~20s
As @guiomie said, the numbers don't add up for serving either: 638+10+1+3+200+1+17+121+149+3+6+18+78+83+3+6+1047 = 2384ms but says 6080ms so seems to be 3696ms going somewhere else.
cetra3
commented
8 years ago 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.
ihorskyi
commented
8 years ago 5269 ms to reload on simple changes on OS X El Capitan with clean ng new
YagoLopez
commented
8 years ago 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.
guiomie
commented
8 years ago @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.
filipesilva
commented
8 years ago Also thanks to all that are posting their numbers, it's very useful to get a benchmark. @intellix's report is specially worrying imho.
YagoLopez
commented
8 years ago @filipesilva thanks for your work, 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.
filipesilva
commented
8 years ago @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.
JohannesRudolph
commented
8 years ago @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.
rdwatters
commented
8 years ago @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!
YagoLopez
commented
8 years ago 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
sharok
commented
8 years ago Some additional info 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
jmlivingston
commented
8 years ago 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
paweloque
commented
8 years ago 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
89889688147bd7575d6327160d64e760.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.
samthomson
commented
8 years ago 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.
kondi
commented
8 years ago 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.
asadsahi
commented
8 years ago @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.
kondi
commented
8 years ago 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?
asadsahi
commented
8 years ago @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 something my head doesn't want to accept or 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.
texel
commented
8 years ago 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.
filipesilva
commented
8 years ago @texel whoa that's impressive, great find! Let me know when that PR is up so I can review.
kondi
commented
8 years ago 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.
texel
commented
8 years ago @filipesilva https://github.com/angular/angular-cli/pull/3008
Just getting the CLA sorted.
intellix
commented
8 years ago Just did a few numbers to check everything with 19-3 using forkChecker:
reload:
ng test reloads with 133 tests:
Would love to know the lowdown on using DLLs. To me it seems an obvious fix with the various frameworks being huge but haven't heard anything from anyone about why it's not used. Any ideas @TheLarkInn?
filipesilva
commented
8 years ago I haven't tested the DLL, but have tested https://github.com/mzgoddard/hard-source-webpack-plugin and noticed no improvement almost.
texel
commented
8 years ago 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.
Meligy
commented
8 years ago @texel does this mean it'd always be notable in ng build?
texel
commented
8 years ago 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.
ng --version. If there's nothing outputted, please run in a Terminal:node --versionand paste the result here: angular-cli: 1.0.0-beta.11-webpack.8 node: 6.3.0 os: win32 x64Mention 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.