Share

An Elementary Guide to Ember Build Performance

When we talk about build performance, it is important to understand that there are several build phases:

  • Cold build
  • Warm build
  • Rebuild

Cold build

Cold build is the build which happens when you boot your app up for the first time. This build is the slowest because the cache is not yet populated and the application is booting for the first time.

 

Build time varies and depends on the number of dependencies that application has but ballpark should be around 5 seconds for small to middle size applications and around 15 seconds for large size applications.

Warm build

Warm build is the build which occurs while you boot your app when cache was populated. This build is faster than cold one because the cache was populated already and it takes less time re-compute dependencies.

 

Build time varies but ballpark should be around 2 seconds for small to middle size applications and around 10 seconds for large size applications.

Rebuild

Rebuild is the subsequent rebuilds that happen on file change. Rebuild aims to be the fastest because it happens the most often.

 

App/ JavaScript Rebuild time varies but ballpark should be around 200-300ms for small to middle size applications and up to 1 second for large size applications (200kloc js + 3000 modules).

The Rebuild is majorly classified into three broad categories based on the asset types like:

  • Rebuild of JS in app/
  • Rebuild of CSS/Sass/Less in app/
  • Rebuild of vendor/, bower_components/

Rebuild of JS in app/

This is likely the most common type of rebuilds, since it concentrates mostly on the javascript assets under app/ folder and is one of the major concerns for the Core Team to improve the performance.

Rebuild of CSS

This kind of rebuilds largely depends on three factors:

  • the size of bower_component (the Ember Core Team have plans to largely mitigate this one)
  • which preprocessor is being used (libsass vs ruby-sass vs less vs …)
  • the amount of CSS

Rebuild of vendor/

This kind of builds are somewhat costly still, due to how slow available sourceMap Libraries are. The Core Team have a work in progress item with a more V8/JIT friendly sourceMap lib, already showing some very nice improvements.

Build Performance Comparison

The various builds are compared based on their characteristics and performance:

These times are based on a posix box with and SSD, win32 unfortunately tends to be slower. As the Core Team continues to improve performance, both posix and win32 will improve, hopefully future work will bring these platforms build times closer together.

If you see that application timings escape, there might be a problem.

Addons known to cause a slow down (but have not yet been addressed):

  • any old non-patch based broccoli plugin
  • ember-cli-component-css
  • ember-browserify
  • … ?

Make sure to mention which type of the build seems to be the problem so we can help identify and fix issues faster.

FAQ/Common Issues & Solutions:

My rebuilds are slow. (And I have anti-virus installed)

The build-system assumes a relative fast/performant file system (although, Ember continue to reduce IO related work). It is quite common for a Anti-virus to slow down IO.

Common issues:

  • anti-virus scanning of tmp, oftentimes this can be avoided altogether.
  • anti-virus on-file-access re-scanning files, oftentimes this can be disabled for the app directory. or ember can be whitelisted.

My rebuilds are slow. (And I am using an encrypted thumb-drive to host my project)

These sorts of drives are notoriously slow. Although Ember continue to reduce our IO overhead, you will be running at a disadvantage. Oftentimes, a much better alternative is hardware supported full-disk encryption, like on most OSX corporate laptops use. This setup is both reasonably secure, and has negligible impact on performance.

My JavaScript rebuilds are still slow.

Please run:

and ideally the following should be true (otherwise some upgrades may be required)

  • broccoli-funnel should be at ^1.0.1
  • broccoli-merge-trees should be at ^1.1.0
  • broccoli-persistent-filter should be at ^1.1.6
  • broccoli-filter often needs to be replaced with broccoli-persistent-filter (we hope to re-merge the two eventually)
  • broccoli-sourcemap-concat should be at ^2.0.2 but will soon be replace by broccoli-concat (we have just re-merged the two)
  • broccoli-caching-writer should be at ^2.2.1
  • broccoli-concat should be at ^2.0.3
  • broccoli-stew should be at ^1.2.0
  • likely more…

Up next we should check for old and deprecate plugins

this should no longer be used, rather broccoli-funnel at v1.0.1 should be used

Up next we should look for not-yet-fixed plugins

npm v3 made my build slow

Well what happened is npm v3 changed the module topology, this coupled with a misbehaving plugin may result in extra files (maybe all of node_modules) being pulled into the build. This is going to be slow.., the solution is to find the offending plugin, and upgrade (or report the issue if it is not yet fixed).

One such plugin is ember-cli-ic-ajax, which has been fixed. So please be sure to upgrade.

Finding such plugins, we can use a series of DEBUG flags, to gain more insight

Despite of all the above scenarios and possible solutions, if the issue still persists, please report an issue in Github with ember-cli project.

Be sure to include:

  • npm version
  • npm ls (as a gist)
  • ideally a reproduction

How to explore/debug and hopefully address performance issues

DEBUG logging

We can use heimdalljs-logger for logging, which supports the same usage as the de-facto standard debug. Quite often this can be used to quickly discover obviously wrong things.

Usage:

For all logging (this will be very verbose):

For all ember-cli logging:

For all broccoli logging:

For both broccoli and ember-cli logging:

The above patterns will be very verbose. But to make them even more verbose you can set the log level via DEBUGLEVEL

To make them a bit less verbose, a curated set of performance related logging flags are:

Because many plugins are used repeatedly it may be difficult to see the context for log entries. By default, 3 nodes of context are shown.

To show more (or fewer) lines of context, specify the environment variable DEBUG_DEPTH

[… ConcatWithMaps#782 -> BroccoliMergeTrees#783] means that the log entry occurred in broccoli merge-trees node with id 783, whose parent was a concat with maps node with id 782. These ids are shown in the visualization graph.

broccoli-viz

  • Visualization

    To visualize build tree, we can use graphviz.

    Graphviz is an open source graph visualization program. Graph visualization is a way of representing structural information as diagrams of abstract graphs and networks. It has important applications in networking, bioinformatics, software engineering, database and web design, machine learning, and in visual interfaces for other technical domains.

    To install it run

    or download it directly from here.

    You will also need to install broccoli-viz version 3.0.3 or higher.

    broccoli-viz is a library to read/parse and produce various visualizations of broccoli.

    To generate visualization:

    To get a better understanding, you can watch this talk:

    Dissecting an ember-cli build by Estelle Deblois

     

    An example visualization graph should look like this, with only a subset of the whole graph cropped for clear understanding.

    Each build will generate an additional graph, instrumentation.build..json

  • in-depth look

    in-depth tooling, aimed to provide much deeper insight into the given build

    • dot: is the input to graphviz, allowing tree visualization
    • json: more detailed counts and timings related to the corresponding build

Cover Image from Unsplash by:

ANDRIK LANGFIELD PETRIDES