Create 0000-daemonize.md

[buschtoens]

RFC

[stefanpenner]

It seems like we should focus on actually addressing any performance issues. Rather then jumping to a complicated multi-process design.

[jakecraige]

I agree with Stef in that focusing on any performance issues is likely the best approach to try first.

This would add a lot of overhead and likely a lot of confusion for new users of ember-cli and ember so ideally we want to avoid that as much as possible.

[buschtoens]

This RFC is mainly just a more elaborate issue, as I felt that this was more suitable form to present this idea.

[stefanpenner]

This RFC is mainly just a more elaborate issue, as I felt that this was more suitable form to present this idea.

You should likely include detailed examples that pin-point the actual performance problems.

I have an app:

• 85,000 app loc
• 48,201 test loc
• 46 ember addons
• 51 bower addons

time ember -v
> ember -v  0.52s user 0.11s system 104% cpu 0.675 total

± % time ember g component foo-bar                                                                                                                                            !12833
version: 0.2.3

A new version of ember-cli is available (0.2.5). To install it, type ember update.
installing
  create app/components/foo-bar.js
  create app/templates/components/foo-bar.hbs
installing
  create tests/unit/components/foo-bar-test.js
ember g component foo-bar  0.55s user 0.10s system 103% cpu 0.608 total

these numbers appear reasonable, but I believe with some careful refactoring we can reduce it further. That is without introducing a complex multi-process setup.

Can you share your pain points and hard numbers?

[buschtoens]

Fresh app

$ time ember generate route test-route
version: 0.2.5
installing
  create app/routes/test-route.js
  create app/templates/test-route.hbs
installing
  create tests/unit/routes/test-route-test.js

real    0m1.976s
user    0m1.868s
sys     0m0.248s

Fresh app, but with addons

$ time ember generate route test-route
version: 0.2.5
installing
  create app/test-route/route.js
  create app/test-route/template.hbs
installing
  create tests/unit/test-route/route-test.js

real    0m3.598s
user    0m3.464s
sys     0m0.400s

I find the difference noticeable, but it isn't as extreme as it was on my old development laptop. On my old laptop it sometimes took up to ten seconds for the task to execute. I don't have it here right now, but I could run a test later, if wanted.

[stefanpenner]

I find the difference noticeable, but it isn't as extreme as it was on my old development laptop. On my old laptop it sometimes took up to ten seconds for the task to execute. I don't have it here right now, but I could run a test later, if wanted.

Can you investigate what is actually causing the slow down? Which files / libs / function calls are causing the issue etc?

As you can see, with my above massive app, I do not see these same numbers. I would like to understand what the root cause is.

[stefanpenner]

the largest offenders appear to be:

20 '/Users/stefanpenner/src/ember-cli/node_modules/lodash/collection/find.js'¬
25 '/Users/stefanpenner/src/ember-cli/node_modules/configstore/node_modules/js-yaml/lib/js-yaml/loader.js'¬
27 '/Users/stefanpenner/src/ember-cli/lib/models/command.js'¬
27 '/Users/stefanpenner/src/ember-cli/node_modules/configstore/node_modules/js-yaml/index.js'¬
27 '/Users/stefanpenner/src/ember-cli/node_modules/configstore/node_modules/js-yaml/lib/js-yaml.js'¬
29 '/Users/stefanpenner/src/ember-cli/node_modules/markdown-it-terminal/lib/markdown-it-terminal.js'¬
35 '/Users/stefanpenner/src/ember-cli/node_modules/configstore/index.js'¬
39 '/Users/stefanpenner/src/ember-cli/node_modules/markdown-it/lib/index.js'¬
40 '/Users/stefanpenner/src/ember-cli/node_modules/markdown-it/index.js'¬
43 '/Users/stefanpenner/src/ember-cli/node_modules/markdown-it-terminal/index.js'¬
62 '/Users/stefanpenner/src/ember-cli/node_modules/leek/node_modules/request/request.js'¬
73 '/Users/stefanpenner/src/ember-cli/node_modules/leek/node_modules/request/index.js'¬
85 '/Users/stefanpenner/src/ember-cli/lib/models/project.js'¬
86 '/Users/stefanpenner/src/ember-cli/lib/utilities/markdown-color.js'¬
126 '/Users/stefanpenner/src/ember-cli/lib/models/blueprint.js'¬
127 '/Users/stefanpenner/src/ember-cli/lib/commands/destroy.js'¬
285 '/Users/stefanpenner/src/ember-cli/lib/cli/index.js'¬

I suspect, an easy win would be to make commands loaded on-demand rather then eagerly. Please note, these numbers are commutative cost of loading a module, so if X requires Y and Y costs 10, X will cost cost(X) + cost(y).

• [ ] make commands load lazily
• [ ] explore the costs of markdown-color
• [ ] do the analytics also cause grief?

[buschtoens]

Can you investigate what is actually causing the slow down? Which files / libs / function calls are causing the issue etc?

How would you recommend going about that?

I suspect, an easy win would be to make commands loaded on-demand rather then eagerly.

I would very much like that! But that would force addon developers to rewrite their plugins, wouldn't it?

[stefanpenner]

Can you investigate what is actually causing the slow down? Which files / libs / function calls are causing the issue etc? How would you recommend going about that?

I suspect, an easy win would be to make commands loaded on-demand rather then eagerly. I would very much like that! But that would force addon developers to rewrite their plugins, wouldn't it?

these are two things that should be identified before writing an RFC.

Typical flow for an RFC:

1. identify a problem
2. discover root cause
3. propose improvement via RFC

Without this, speculative solution for an RFC provides very little value and is mostly distracting and time consuming for myself and other reviewers.

[buschtoens]

Closing for obvious reasons, but maybe this will be interesting in the future. :)

Anyway, how would you recommend profiling the performance of ember-cli?