Why the ember-cli is so slow

Question

I migrated my grunt project to ember-cli, I found the time from file modification to liveload completion was so long, about 10 minutes.

After I installed ember-cli-wind

Answer 1

The best solution for fixing performance issues in windows is running a Ubuntu (or whatever linux you want) in a virtual machine, and running ember serve inside it, using NFS to share folders with host.

I had the exact same problem and I'm getting now sub-second building times. Tried all the solutions found here and in the internet, but without luck. I got 10x performance when I migrated to a Ubuntu VM.

Answer 2

For windows users, one will need to correctly enable symlinks. As our friends at Microsoft are actually active users of both ember and ember-cli. They have provided an addon that does exactly that.

See: http://ember-cli.com/user-guide/#windows for further details. For all users see: https://github.com/ember-cli/ember-cli/blob/master/PERF_GUIDE.md

[Update]

In the last 6 months several large performance improvements have landed, some are seeing one or two orders of magnitude improvements (obviously this depends on some factors...)

As time permits, more performance improvements are planned, one particular important one is decoupling the need to rely on symlinks or copying. Which should make our windows counterparts (and those with slower drives) quite happy.

For anyone currently feeling like they are seeing less then optimal performance, let me recommend this guide: https://github.com/ember-cli/ember-cli/blob/master/PERF_GUIDE.md

Many of the recent improvements have been done in a backwards compatible way, but do require dependencies being upgraded, be sure to upgrade relevant depends, and use that guide to track down any remaining issues and report them.

---

Windows Subsystem Linux also appears to now work very well!

Answer 3

You ask

Why the ember-cli is so slow

It is not ember-cli per se that is slow, it is Broccoli. Reasons include:

1. Broccoli copies files instead of symlinking under Windows. To avoid this, run your builds in a command prompt with administrator privileges.

2. Broccoli is disk-intensive. To solve this, get an SSD.

3. Broccoli is processor intensive. To solve this, get a faster machine (preferably non-Windows).

4. Broccoli creates huge numbers of temporary files in tmp, which can slow down performance. To solve this, clean out tmp from time to time.

5. Broccoli is known to be inherently slow. You can find relevant questions on the broccoli site. To solve this, wait for the broccoli people to address performance issues, which is on their roadmap. Substantial improvements have already been made, so upgrade to the latest version of everything.

6. Broccoli rebuilds everything over and over again, including things which did not change. To solve this, manually tweak your build process to exclude certain things and do them manually as-needed. For instance, let's say you are bringing in a 200KB external JS package via bower, and app.import'ing it in your Brocfile.js. As a temporary work-around, and to see if it makes a difference, remove that file from the Broccoli world and load it directly in index.html. The same applies to large CSS files.

7. Broccoli will run babel in a default installation. Babel is not that slow, but it does take time. To solve this, if you are not using ES6 syntax, remove the babel dependency.

8. Your virus scanner may be trying to scan the thousands of files Broccoli creates. ember-cli-windows deals with this problem only for Defender. If you are using a different anti-virus package, to solve this add your dev directory to its list of places to skip.

For your reference, I have a small Ember project I build in an Ubuntu Virtual Box VM with Windows host on a fast machine with SSD, and builds take 2-3 seconds.

You may also want to consider asking this on an ember-cli list. You could also choose a different framework that does not bake in an immature and inefficient build system.