Ember-cli: A 9-10 minute first load time (not build, this is require / fs read time)
Setup
Output from ember version --verbose:
ember-cli: 2.7.0
http_parser: 2.7.0
node: 6.3.1
v8: 5.0.71.57
uv: 1.9.1
zlib: 1.2.8
ares: 1.10.1-DEV
icu: 57.1
modules: 48
openssl: 1.0.2h
os: linux x64 (ubuntu 16.04 LTS)
Time required
I've created a vanilla ember app with with ember new command, cd into the directory and run the ember server.
Here's the output with time-require enabled:
Livereload server on http://localhost:49152
Serving on http://localhost:4200/
Build successful - 80019ms.
Slowest Trees | Total
----------------------------------------------+---------------------
Babel | 13367ms
Babel | 8426ms
SourceMapConcat: Concat: Addon JS | 4163ms
Slowest Trees (cumulative) | Total (avg)
----------------------------------------------+---------------------
Babel (12) | 31643ms (2636 ms)
SourceMapConcat: Concat: Addon JS (1) | 4163ms
Funnel: Addon JS (6) | 4003ms (667 ms)
Start time: (2016-08-01 19:46:09 UTC) [treshold=1%]
# module time %
1 ../models/proj...s/project.js) 6.2s ▇ 1%
2 /media/musaffa...cli/index.js) 10.4s ▇ 2%
3 ../dist/cjs/ha...andlebars.js) 6.5s ▇ 1%
4 handlebars (no...lib/index.js) 6.8s ▇ 1%
5 ./middleware (...iddleware.js) 7.3s ▇ 1%
6 ./server (node...ib/server.js) 11.9s ▇ 2%
7 ember-cli-broc...lib/index.js) 17.5s ▇ 3%
8 lodash/array/u...rray/uniq.js) 6.6s ▇ 1%
9 ../../types (n...pes/index.js) 18.3s ▇ 3%
10 ../../../trans...ers/react.js) 18.4s ▇ 3%
11 ./lib/virtual-...ual-types.js) 18.6s ▇ 3%
12 babylon (node_...lib/index.js) 6.5s ▇ 1%
13 ../../helpers/...ers/parse.js) 6.6s ▇ 1%
14 ./replacement...placement.js) 7.4s ▇ 1%
15 ./path (node_m...ath/index.js) 32.4s ▇▇ 6%
16 ./context (nod...l/context.js) 32.7s ▇▇ 6%
17 ../traversal (...sal/index.js) 35s ▇▇ 6%
18 ./plugin-pass...ugin-pass.js) 35.1s ▇▇ 6%
19 ../modules (no...les/index.js) 7.4s ▇ 1%
20 ../../generati...ion/index.js) 6.6s ▇ 1%
21 ./file (node_m...ile/index.js) 20.8s ▇▇ 4%
22 ./plugin (node...on/plugin.js) 56.3s ▇▇▇ 10%
23 ../transformer...ansformer.js) 56.4s ▇▇▇ 10%
24 ./file/plugin-...n-manager.js) 56.6s ▇▇▇ 10%
25 ./pipeline (no.../pipeline.js) 57.2s ▇▇▇ 10%
26 recast (node_m...cast/main.js) 7.2s ▇ 1%
27 ./lib/visit (n...lib/visit.js) 8.2s ▇ 1%
28 regenerator (n...ator/main.js) 9.1s ▇ 2%
29 ./other/regene...generator.js) 9.3s ▇ 2%
30 ./transformers...ers/index.js) 30.6s ▇▇ 5%
31 ../transformat...ion/index.js) 1m 28.5s ▇▇▇▇▇ 15%
32 ./lib/api/node.../api/node.js) 1m 31.2s ▇▇▇▇▇ 16%
33 babel-core (no...ore/index.js) 1m 31.4s ▇▇▇▇▇ 16%
34 broccoli-persi...ter/index.js) 7.5s ▇ 1%
35 broccoli-babel...ler/index.js) 1m 39.5s ▇▇▇▇▇▇ 17%
36 broccoli-cachi...ter/index.js) 6.5s ▇ 1%
37 ./concat (node...at/concat.js) 7.2s ▇ 1%
38 broccoli-conca...cat/index.js) 7.4s ▇ 1%
39 fs-extra (node...lib/index.js) 7.2s ▇ 1%
40 broccoli-confi...ace/index.js) 9.8s ▇ 2%
41 ember-cli/lib/...ember-app.js) 2m 3.7s ▇▇▇▇▇▇▇ 22%
42 /media/musaffa...cli-build.js) 2m 3.7s ▇▇▇▇▇▇▇ 22%
43 broccoli-persi...ter/index.js) 8.9s ▇ 2%
44 ./index (node_...ars/index.js) 9.3s ▇ 2%
45 ../../types (n...pes/index.js) 9.5s ▇ 2%
46 ../../../trans...ers/react.js) 9.6s ▇ 2%
47 ./lib/virtual-...ual-types.js) 9.7s ▇ 2%
48 ./path (node_m...ath/index.js) 19.7s ▇▇ 3%
49 ./context (nod...l/context.js) 20s ▇▇ 3%
50 ../traversal (...sal/index.js) 21.3s ▇▇ 4%
51 ./plugin-pass...ugin-pass.js) 21.3s ▇▇ 4%
52 ./file (node_m...ile/index.js) 14.9s ▇ 3%
53 ./plugin (node...on/plugin.js) 36.6s ▇▇ 6%
54 ../transformer...ansformer.js) 36.7s ▇▇ 6%
55 ./file/plugin-...n-manager.js) 36.9s ▇▇ 6%
56 ./pipeline (no.../pipeline.js) 37.3s ▇▇ 7%
57 ./lib/visit (n...lib/visit.js) 6.3s ▇ 1%
58 regenerator (n...ator/main.js) 6.9s ▇ 1%
59 ./other/regene...generator.js) 7s ▇ 1%
60 ./transformers...ers/index.js) 24.9s ▇▇ 4%
61 ../transformat...ion/index.js) 1m 2.7s ▇▇▇▇ 11%
62 ./lib/api/node.../api/node.js) 1m 4.6s ▇▇▇▇ 11%
63 babel-core (no...ore/index.js) 1m 4.7s ▇▇▇▇ 11%
64 broccoli-persi...ter/index.js) 6.9s ▇ 1%
65 broccoli-babel...ler/index.js) 1m 19.4s ▇▇▇▇▇ 14%
66 ./lib/express...b/express.js) 6.6s ▇ 1%
67 express (node_...ess/index.js) 6.7s ▇ 1%
Total require(): 8441
Total time: 9m 32s
If I restart the server then I get the the following result:
Livereload server on http://localhost:49152
Serving on http://localhost:4200/
Build successful - 2230ms.
Slowest Trees | Total
----------------------------------------------+---------------------
Babel | 213ms
SourceMapConcat: Concat: Vendor /assets/ve... | 159ms
Babel | 150ms
Slowest Trees (cumulative) | Total (avg)
----------------------------------------------+---------------------
Babel (12) | 637ms (53 ms)
SourceMapConcat: Concat: Vendor /asset... (1) | 159ms
Start time: (2016-08-01 20:04:10 UTC) [treshold=1%]
# module time %
1 ../models/proj...s/project.js) 281ms ▇ 1%
2 /media/musaffa...cli/index.js) 463ms ▇ 2%
3 ./plugin (node...on/plugin.js) 339ms ▇ 1%
4 ../transformer...ansformer.js) 340ms ▇ 1%
5 ./file/plugin-...n-manager.js) 342ms ▇ 1%
6 ./pipeline (no.../pipeline.js) 345ms ▇ 1%
7 ../transformat...ion/index.js) 623ms ▇ 2%
8 ./lib/api/node.../api/node.js) 633ms ▇ 2%
9 babel-core (no...ore/index.js) 634ms ▇ 2%
10 broccoli-babel...ler/index.js) 677ms ▇ 2%
11 ember-cli/lib/...ember-app.js) 872ms ▇ 3%
12 /media/musaffa...cli-build.js) 872ms ▇ 3%
13 ./plugin (node...on/plugin.js) 333ms ▇ 1%
14 ../transformer...ansformer.js) 334ms ▇ 1%
15 ./file/plugin-...n-manager.js) 337ms ▇ 1%
16 ./pipeline (no.../pipeline.js) 340ms ▇ 1%
17 ../transformat...ion/index.js) 609ms ▇ 2%
18 ./lib/api/node.../api/node.js) 618ms ▇ 2%
19 babel-core (no...ore/index.js) 619ms ▇ 2%
20 broccoli-babel...ler/index.js) 755ms ▇ 3%
Total require(): 8441
Total time: 11s
This gives a satisfactory result.
But If I reboot the computer and then run this server, it again starts to take around 9 to 10 minutes to load the app just like the first output scenario.
Debug Output
Here's the debug output of the first build with DEBUG=* settings enabled: https://gist.github.com/musaffa/3820d26eb06e41f81784d1579e661801
The greatest delays occur at ember-cli:registry - 3 minute 15 seconds:
Mon, 01 Aug 2016 18:33:36 GMT ember-cli:watcher watchman 4.5.0 does satisfy: >= 3.0.0
Mon, 01 Aug 2016 18:36:51 GMT ember-cli:registry add type: js, name: ember-cli-babel, extension:js, options:undefined
Then at async-disk-cache - 1 minute 13 second delay:
Mon, 01 Aug 2016 18:37:02 GMT ember-cli:registry loading htmlbars-ast-plugin: available plugins ; found plugins ;
Mon, 01 Aug 2016 18:38:15 GMT async-disk-cache new Cache { root: /tmp/if-you-need-to-delete-this-open-an-issue-async-disk-cache/ef5ea5c2c57032da13f0e43785ab4cb6, compression: deflate }
Then at async-disk-cache - 3 minute 51 seconds:
Mon, 01 Aug 2016 18:38:16 GMT ember-cli:preprocessors processing ember-cli-babel
Mon, 01 Aug 2016 18:42:07 GMT async-disk-cache new Cache { root: /tmp/if-you-need-to-delete-this-open-an-issue-async-disk-cache/467a766139d2aad8bd700a63ebf2abf3, compression: deflate }
And so on.
Problems at a glance:
- The Initial load after the project creation is very slow (9-10 min).
- Restart the server. Now it loads faster (2-15 s).
- Reboot the computer. Now again the load becomes very slow (9-10 min).
- Restart the server. Now it loads faster (2-15 s).
musaffa
All 51 comments
this seems somewhat related to https://github.com/ember-cli/ember-cli/issues/6009, but the times you're seeing are waaaaay worse so I guess there is probably something else going on. do you have access to another machine to see if it's related to your setup or if it's a general problem?
Turbo87
on 1 Aug 2016
It looks like a general problem. I've tested this in my brother's laptop on Ubuntu 14.04. The problem also persists if I try this with node 4.4.7.
musaffa
on 1 Aug 2016
80019ms is 1.3 minutes, not 8 or 9 minutes.
stefanpenner
on 1 Aug 2016
It takes 6-7 minutes before I see this in the console:
Livereload server on http://localhost:49152
Serving on http://localhost:4200/
how long does time ember version take?
stefanpenner
on 1 Aug 2016
oh sorry, I just noticed:
31 ../transformat...ion/index.js) 1m 28.5s ▇▇▇▇▇ 15%
32 ./lib/api/node.../api/node.js) 1m 31.2s ▇▇▇▇▇ 16%
33 babel-core (no...ore/index.js) 1m 31.4s ▇▇▇▇▇ 16%
It is actually several minutes to require a file...
stefanpenner
on 1 Aug 2016
Do you have any or all of the following?
- an encrypted drive
- running off thumb-drive or external drive
- running off a network mount?
- anti-virus?
Which file system?
stefanpenner
on 1 Aug 2016
@Turbo87 I wonder if we should try doing a rollup of babel...
stefanpenner
on 1 Aug 2016
/media/musaffa suggests this is some sort of foreign mount.
stefanpenner
on 1 Aug 2016
Can you share more details of your setup?
stefanpenner
on 1 Aug 2016
@musaffa what does /etc/fstab look like?
hjdivad
on 1 Aug 2016
Do you have any or all of the following?
1. an encrypted drive
2. running off thumb-drive or external drive
3. running off a network mount?
No
musaffa
on 1 Aug 2016
Output of /etc/fstab:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
#Entry for /dev/sda1 :
UUID=c3600282-30b7-4d28-a916-fdc494348843 / ext4 errors=remount-ro 0 1
#Entry for /dev/sda5 :
UUID=DCCA9102CA90D9DA /media/musaffa/graphics ntfs-3g defaults,nodev,nosuid,locale=en_US.UTF-8 0 0
#Entry for /dev/sda7 :
UUID=0ACE3EBECE3EA23D /media/musaffa/inventory ntfs-3g defaults,nodev,nosuid,locale=en_US.UTF-8 0 0
#Entry for /dev/sda6 :
UUID=EEE4EC47E4EC139D /media/musaffa/others ntfs-3g defaults,nodev,nosuid,locale=en_US.UTF-8 0 0
#Entry for /dev/sda8 :
UUID=D67A9A0F7A99ED0D /media/musaffa/workshop ntfs-3g defaults,nodev,nosuid,locale=en_US.UTF-8 0 0
#Entry for /dev/sda9 :
UUID=cea09f57-9b22-4e58-b33c-425e9b667d94 none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0
My project resides on /media/musaffa/workshop.
musaffa
on 1 Aug 2016
side note: @musaffa this is a really great issue report, thank you :)
stefanpenner
on 1 Aug 2016
Can you confirm, it appears you are mounting drives from a windows partition using NTFS-3G via fuse? Can you describe your setup abit further, is this a VM on windows, or a dual boot system or....
stefanpenner
on 1 Aug 2016
I've mounted with NTFS configuration tool with permanent read and write access.
musaffa
on 1 Aug 2016
But I can try this setup on my ext4 drive.
musaffa
on 1 Aug 2016
@musaffa that would be great. Our current hypothesis is that this cost is coming from ntfs-3g; it would be helpful to confirm or eliminate this hypothesis.
hjdivad
on 1 Aug 2016
To prevent any confusion, @hjdivad are actually pairing right now.
stefanpenner
on 1 Aug 2016
It may take 10-20 mintues. Please wait.
musaffa
on 1 Aug 2016
thanks @musaffa
hjdivad
on 1 Aug 2016
Yay! Build has become much faster in ext4 filesystem. Here's the output with time-require:
Livereload server on http://localhost:49152
Serving on http://localhost:4200/
Build successful - 14296ms.
Slowest Trees | Total
----------------------------------------------+---------------------
Babel | 4339ms
Babel | 4237ms
Babel | 978ms
Babel | 906ms
Slowest Trees (cumulative) | Total (avg)
----------------------------------------------+---------------------
Babel (12) | 11342ms (945 ms)
Start time: (2016-08-01 22:10:54 UTC) [treshold=1%]
# module time %
1 fs-extra (node...lib/index.js) 678ms ▇ 1%
2 ../models/proj...s/project.js) 1.7s ▇ 3%
3 /home/musaffa/...cli/index.js) 2.6s ▇▇ 4%
4 yam (node_modu...m/lib/yam.js) 782ms ▇ 1%
5 ../models/addo...els/addon.js) 739ms ▇ 1%
6 broccoli-jshin...int/index.js) 1s ▇ 2%
7 /home/musaffa/...int/index.js) 1s ▇ 2%
8 ./request (nod...t/request.js) 1s ▇ 2%
9 request (node_...est/index.js) 1.2s ▇ 2%
10 ./builder (nod...b/builder.js) 702ms ▇ 1%
11 handlebars (no...lib/index.js) 664ms ▇ 1%
12 ./middleware (...iddleware.js) 774ms ▇ 1%
13 ./server (node...ib/server.js) 1.2s ▇ 2%
14 ember-cli-broc...lib/index.js) 2s ▇ 3%
15 ../../types (n...pes/index.js) 969ms ▇ 2%
16 ../../../trans...ers/react.js) 988ms ▇ 2%
17 ./lib/virtual-...ual-types.js) 1s ▇ 2%
18 ./path (node_m...ath/index.js) 1.7s ▇ 3%
19 ./context (nod...l/context.js) 1.7s ▇ 3%
20 ../traversal (...sal/index.js) 1.8s ▇ 3%
21 ./plugin-pass...ugin-pass.js) 1.8s ▇ 3%
22 ./file (node_m...ile/index.js) 1.1s ▇ 2%
23 ./plugin (node...on/plugin.js) 2.9s ▇▇ 5%
24 ../transformer...ansformer.js) 2.9s ▇▇ 5%
25 ./file/plugin-...n-manager.js) 3s ▇▇ 5%
26 ./pipeline (no.../pipeline.js) 3s ▇▇ 5%
27 recast (node_m...cast/main.js) 646ms ▇ 1%
28 ./lib/visit (n...lib/visit.js) 725ms ▇ 1%
29 regenerator (n...ator/main.js) 745ms ▇ 1%
30 ./other/regene...generator.js) 746ms ▇ 1%
31 ./transformers...ers/index.js) 1.9s ▇ 3%
32 ../transformat...ion/index.js) 4.9s ▇▇▇ 8%
33 ./lib/api/node.../api/node.js) 5.1s ▇▇▇ 8%
34 babel-core (no...ore/index.js) 5.1s ▇▇▇ 8%
35 broccoli-babel...ler/index.js) 5.5s ▇▇▇ 9%
36 broccoli-cachi...ter/index.js) 660ms ▇ 1%
37 ./concat (node...at/concat.js) 776ms ▇ 1%
38 broccoli-conca...cat/index.js) 822ms ▇ 1%
39 fs-extra (node...lib/index.js) 1.1s ▇ 2%
40 broccoli-confi...ace/index.js) 1.4s ▇ 2%
41 ember-cli/lib/...ember-app.js) 8.5s ▇▇▇▇▇ 14%
42 /home/musaffa/...cli-build.js) 8.5s ▇▇▇▇▇ 14%
43 broccoli-persi...ter/index.js) 917ms ▇ 1%
44 ./index (node_...ars/index.js) 991ms ▇ 2%
45 ./lib/strategi...ersistent.js) 631ms ▇ 1%
46 ../../types (n...pes/index.js) 987ms ▇ 2%
47 ../../../trans...ers/react.js) 990ms ▇ 2%
48 ./lib/virtual-...ual-types.js) 997ms ▇ 2%
49 ./path (node_m...ath/index.js) 1.9s ▇ 3%
50 ./context (nod...l/context.js) 1.9s ▇ 3%
51 ../traversal (...sal/index.js) 2s ▇ 3%
52 ./plugin-pass...ugin-pass.js) 2s ▇ 3%
53 ./file (node_m...ile/index.js) 1.1s ▇ 2%
54 ./plugin (node...on/plugin.js) 3s ▇▇ 5%
55 ../transformer...ansformer.js) 3.1s ▇▇ 5%
56 ./file/plugin-...n-manager.js) 3.1s ▇▇ 5%
57 ./pipeline (no.../pipeline.js) 3.1s ▇▇ 5%
58 regenerator (n...ator/main.js) 684ms ▇ 1%
59 ./other/regene...generator.js) 696ms ▇ 1%
60 ./transformers...ers/index.js) 1.8s ▇ 3%
61 ../transformat...ion/index.js) 5s ▇▇▇ 8%
62 ./lib/api/node.../api/node.js) 5s ▇▇▇ 8%
63 babel-core (no...ore/index.js) 5.1s ▇▇▇ 8%
64 broccoli-persi...ter/index.js) 1s ▇ 2%
65 broccoli-merge...ees/index.js) 976ms ▇ 2%
66 broccoli-funne...nel/index.js) 742ms ▇ 1%
67 broccoli-babel...ler/index.js) 7.9s ▇▇▇▇ 13%
68 broccoli-merge...ees/index.js) 895ms ▇ 1%
69 async-disk-cac...che/index.js) 632ms ▇ 1%
70 ./lib/strategi...ersistent.js) 655ms ▇ 1%
71 ./lib/express...b/express.js) 827ms ▇ 1%
72 express (node_...ess/index.js) 853ms ▇ 1%
73 ./server (node...ib/server.js) 732ms ▇ 1%
74 tiny-lr (node_...lib/index.js) 759ms ▇ 1%
Total require(): 8441
Total time: 1m 2.6s
@musaffa mystery solved.
I don't believe we can do much to improve the performance os NTFS-3g. We have on-going efforts to reduce the number of dependencies, and their cost to us. But having a slow on-first-use filesystem will unfortunately pwn us.
One upside is that we now know this problem exists, and can help future users who also encounter it.
stefanpenner
on 2 Aug 2016
@musaffa thank you for an excellent bug report, if you have any ideas on how else we can improve this we are all ears. Otherwise I suspect we must close this one.
stefanpenner
on 2 Aug 2016
I'm switching all my projects to ext4 filesystem.
Thank you guys. You're awesome. :heart:
musaffa
on 2 Aug 2016
@musaffa <3
stefanpenner
on 2 Aug 2016
Update on the issue upon migrating from mounted ntfs drive to ext4 filesystem:
Initial file requirement time: 48 seconds
Initial build time: 13 seconds
Total : ~ 1 minute
musaffa
on 2 Aug 2016
@locks This might be an issue you want to be aware of too.
kellyselden
on 2 Aug 2016
Initial file requirement time: 48 seconds
This is still pretty high, might be hardware related? or.. Can you share your project (privately if you can't oss it)
stefanpenner
on 2 Aug 2016
I'm still curious whats taking those last 48 seconds...
stefanpenner
on 2 Aug 2016
Are you on SSD or HDD or USB stick or external drive of some kind?
stefanpenner
on 2 Aug 2016
Are you on SSD or HDD or USB stick or external drive of some kind?
HDD
musaffa
on 2 Aug 2016
Can you share your project?
This setup is just a vanilla ember app created with ember new command. No extra feature has been added to it.
musaffa
on 2 Aug 2016
@musaffa ah ok. Unfortunately, then I am somewhat unsure what we can do. Is the second load much better?
Also what is your HDD RPM/throughput
- s
stefanpenner
on 2 Aug 2016
Yes much better.
What is your HDD RPM/throughput?
7200 rpm
musaffa
on 2 Aug 2016
@stefanpenner A further investigation with two vanilla ember apps.
Scenario 1: Project creation
- create app-1
- create app-2
- run one after another
Time taken for app-1: initial load time 15s, initial build time 10s
Time taken for app-2: initial load time 15s, initial build time 10s
Scenario 2: First reboot
- Run app-1 first then app-2
Time taken for app-1: initial load time 1 minute 45s, initial build time 20s
Time taken for app-2: initial load time 20s, initial build time 15s
Scenario 3: Second reboot
- Run app-2 first then app-1
Time taken for app-1: initial load time 20s, initial build time 15s
Time taken for app-2: initial load time 1 minute 45s, initial build time 20s
Observations
- Initial load time after project creation is quite fast
- Initial load time of the same app becomes slower after reboot
- After reboot if I run two ember apps, then second app's initial load time is always and much faster then the first app. If I change the sequence after reboot, the app which is run later is always faster.
musaffa
on 2 Aug 2016
@musaffa so it seems something needs to be "warmed" up first? Maybe some power-savings mode or... Anyways, that's annoying...
I'm not to sure what we can do short term. Long term we have hopes of removing more dependencies, and bundling the costly ones. Which may help some.
stefanpenner
on 2 Aug 2016
How do u plan to rollup Babel when 100% support for es6 has not yet been landed in node and browsers?
musaffa
on 3 Aug 2016
@musaffa rollup is tool, to combine multiple dependencies into single files. In theory this may reduce extra disk IO and reduce as much random IO.
Im not sure there is much directly actionable at the moment. We have on-going plans to reduce the weight of the project, but even doing what I imagine, I am unsure if it would address the issue of a slow spin-up time described here.
@musaffa do you have any ideas?
stefanpenner
on 3 Aug 2016
@stefanpenner We can do partial transpilation in development and test builds. ES6 is fully backward compatible with ES5 so a single javascript file can contain both ES6 and ES5 codes which can be executed by an ES6 engine. For partial transpilation, we can utilize babel's preset feature to cherry pick only those features which are not yet been supported in a node version. There's some presets already available:
node 4: babel-preset-es2015-node4
node 5: babel-preset-es2015-node5, babel-preset-node5
node 6: babel-preset-es2015-node6, babel-preset-node6
The higher the node version, the lower the partial transpilation and, hopefully, the lower the build time. With node specific presets, the job of babel will be to complement V8's existing native ES6 funtionalities. When the full support of ES6 eventually lands in nodejs, babel wont be required to complement any ES6 feature. Babel will still be required for ES7, ESnext features and, of course, for production builds which needs to be fully transpiled into ES5.
As newer V8 versions come first in chrome than do in nodejs, we can safely assume that the build produced by nodejs will work in the latest chrome as well. Firefox can be problematic as ES6 features land a bit slowly there. Here's the ES6 compatability table.
Instead of forcing all the developers into adopting partial transpilation, it can be made into a separate addon.
musaffa
on 3 Aug 2016
@musaffa that doesn't sounds like it would solve the issue, as the issue here isn't transpilation at all (that all actually seems to run fine) but rather merely requiring files of your HD.
stefanpenner
on 3 Aug 2016
Doesn't less transpilation mean less IO operations during a build?
musaffa
on 3 Aug 2016
@musaffa not really, the issue is merely requiring the code to run the the CLI, not the build itself. That is with the exception of the disk cache.
I think we can continue to reduce the "weight" of a dep tree, but rolling it up or similar, but it'll be tricky to mitigate entirely.
stefanpenner
on 3 Aug 2016
@stefanpenner I wonder whether the reboot issues as shown in the above scenarios are just Ubuntu ext4 specific. Does it happen in OS X too?
musaffa
on 4 Aug 2016
@musaffa my linx box is much faster then OSX (and even when testing in a linux vm on OSX). Linux typically seems much faster.
One guess is maybe power savings mode causing HDD spin-down would explain the slow first reads, but fast subsequent. Or maybe something else I am unaware of on your setup. (or something else funky?)
stefanpenner
on 4 Aug 2016
@stefanpenner I've just noticed that although moving from ntfs to ext4 has certainly made the load time faster but the behaviour hasn't changed at all. For example, ember-cli-build.js required 2 mintues in ntfs and now it takes 19s in ext4. All the files which required longer load times in ntfs also now requires longer load time, albeit faster, in ex4. The pattern remains the same.
I believe it has something to do with my setup. I will do further investigation and notify you if I find any clue.
musaffa
on 4 Aug 2016
@musaffa I am genuinely curious, and if it turns out there is something we can do to mitigate (or plan to mitigate) or at the very least document so future users can also benefit, I would love us too.
Thank you for helping dig into this further :)
stefanpenner
on 4 Aug 2016
In parallel https://github.com/ember-cli/ember-cli/issues/6147 I am doing an audit and opening issues, so we can reduce the overall filecount of a typical ember-cli install.
stefanpenner
on 4 Aug 2016
@stefanpenner That the second app being run is always faster is likely because @musaffa is triggering a broccoli-persistent-cache hash collision since they're both vanilla Ember applications.
The reboot is clearing the discard of the persistent cache so the first one run takes 1 minute 45 seconds.
At this point I'm closing this issue as "no longer actionable" and focus should switch to #6147.
@musaffa Thank you again, tremendously, for this fantastic bug report.
nathanhammond
on 8 Aug 2016
@stefanpenner That the second app being run is always faster is likely because @musaffa is triggering a broccoli-persistent-cache hash collision since they're both vanilla Ember applications.
@nathanhammond please read the backlog carefully, it isn't related to persistent-cache. It is merely any disc access. Once the disk is spun up (or stuff is loaded) all appears well. I also believe this to be somewhat non-actionable, but we will continue to reduce the "weight" of ember-cli which may help.
stefanpenner
on 8 Aug 2016
@stefanpenner This is the part which I feel like is definitely explained by a broccoli-persistent-cache collision:
First reboot, run app-1 first then app-2:
- Time taken for app-1: initial load time 1 minute 45s, initial build time 20s
- Time taken for app-2: initial load time 20s, initial build time 15s
Second reboot, run app-2 first then app-1:
- Time taken for app-2: initial load time 1 minute 45s, initial build time 20s
- Time taken for app-1: initial load time 20s, initial build time 15s
nathanhammond
on 8 Aug 2016
Related issues
aluink
·
37Comments
zoltan-nz
·
42Comments
ssured
·
47Comments
twokul
·
30Comments
nathanpalmer
·
30Comments
Most helpful comment
side note: @musaffa this is a really great issue report, thank you :)