Optimizing Ember and Ember-CLI on Windows

Optimizing Ember and Ember-CLI on Windows

By Felix Rieseberg, Partner Catalyst Team

 

Ember is one of the most popular MVC web frameworks available today - Yahoo, Vine, Groupon, LinkedIn, ZenDesk are only few of the websites built with it. This case study describes the development and usage of ember-cli-windows, a small command-line utility greatly improving the developer experience by reducing build times for Ember users running Windows 10, 8.1, 8, or 7. The tool has now become the official way of running Ember-CLI on Windows.  This technique can be more broadly applied to optimize any scenario involving lots of disk read/write operations.

 

Customer Problem

A core component of Ember is its powerful tooling: Ember CLI is a command-line client that makes it easier to scaffold, test, develop and build complex web applications. One of the main features is the build process.  Ember-CLI transpiles modern JavaScript code (ECMAScript 6) or JavaScript-like languages (TypeScript, CoffeeScript, etc.) and dependencies into optimized, backwards-compatible ECMAScript 5 JavaScript code. This process is run during development whenever a file change occurs (to render the live preview of the web app), during testing, and when the app is built for production.

 

On Windows, the build process can be magnitudes slower than on Linux or Mac OS X. Since the build process is executed in response to any local file change during development, Windows developers quickly find themselves staring at a slow “Building… ” multiple times in an hour, wondering why the same build only takes seconds on OS X and Linux

 

Why does this happen?   It turns out that two services, Windows Defender and the Windows Search Index monitor new files and writes to existing files.   These services are valuable and important – Windows Defender protects against viruses, and Windows Search Index ensures that you can find what you’re looking for on your machine.  But this good and valuable work has unintended consequences.  During the build process, many temporary files get created by the various code transpilers. As this happens, Windows Defender and Windows Search Index examine and lock these temporary files. While the two services check thousands of small files, the developer sits and waits.

 

Overview of the Solution

A solution exists: Since the temporary files are simply copies of existing code, the user can safely disable both the Windows Search Index and Windows Defender for the local tmp folder in an Ember application source folder. 

 

Ember-CLI-Windows was developed in close collaboration with the Ember team and open source volunteers to automate the full configuration (including the disabling step mentioned above), enabling users to simply run ember-cli-windows in any source folder to reduce build times by up to 70%.

 

The same practice can be used to optimize the performance of any scenario involving lots of disk read/write operations.  See https://social.technet.microsoft.com/wiki/contents/articles/953.microsoft-anti-virus-exclusion-list.aspx for more details.

 

Implementation

At the core, Ember-CLI-Windows is a Node.js command-line tool that programmatically invokes PowerShell scripts to determine the current version of Windows and the current user rights.  Then it appropriately configures both Windows Defender and the Windows Search Index.

 

function runPowershell(scriptPath, name, cb) {

    var child = spawn('powershell.exe', ['-NoProfile', '-NoLogo', "& {& '"+ scriptPath + "' -

path '" + dir + "'}"]), // jshint ignore:line

        output = [];

 

    child.stdout.on('data', function (data) {

        console.log(data.toString());

        output.push(data.toString());

    });

 

    child.stderr.on('data', function (data) {

        console.log('Configuration Error: ', data.toString());

        output.push(data.toString());

    });

 

    child.on('exit', function () {

        console.log(name + ' configured!');

        cb(output);

    });

 

    child.stdin.end();

}

 

Snippet 1: Running PowerShell from Node.js (backwards-compatible to Windows 7 

The two PowerShell scripts (setup-defender.ps14 and setup-search.ps15) were initially only written to support Windows 8.1 and later versions, but the open source community quickly stepped in to provide backwards compatibility for Windows 7 (Thanks to bschuedzig, kellyselden, Jackbennet and petetnt! ).

 

Installing and using Ember-CLI-Windows

Ember-CLI-Windows comes in two forms: a standalone command line client for users who are developing multiple applications, and a non-global addon to Ember-CLI. In both cases, Node.js and NPM are required (as they are for Ember-CLI).

 

To install and execute the standalone version, simply run: 

npm install ember-cli-windows -g

ember-cli-windows

 

Should you get a PSSecurityException, allow your PowerShell to execute the script. Run the following command as Administrator: 

 Set-ExecutionPolicy Unrestricted -scope Process
 ember-cli-windows

 

Installing and using Ember-CLI-Windows as an Ember Addon

Ember-CLI-Windows can be invoked from any Ember-CLI installation. If you’re already in a scaffolded Ember-CLI application, simply install the addon by running the following command:

 npm install --save-dev ember-cli-windows-addon

To execute Ember-CLI-Windows, just run:

 ember windows

 

Performance Gained

Mileage varies, but some users were kind enough to share their results. In the case of this Dutch company, the build time went from 41 seconds to 8 seconds.

 

Challenges

Automating the configuration on Windows 8.1 and later versions was quite easy, while achieving the same goal on Windows 7 was much more difficult. The advances Windows has made in command line automation since Windows 8 were very clear. Before Windows 8.1, edge-cases like special user groups, group policies, folder names with special characters, etc. required some PowerShell magic. In the case of Windows Search, we bundled an Interop DLL to shim features missing in PowerShell v1.

 

Opportunities for Reuse

The same challenge exists whenever code generators and other tools create and destroy a large number of temporary files in a non OS-level temp folder. While the use case sounds unique, it is common for open-source tools to not rely on the operating system’s “temp” folder so that the tool will operate in a platform-agnostic way. 

 

Felix Rieseberg is an Open Source Engineer in Microsoft's Partner Catalyst team where he spends his time coding on the cutting edge of technology, trying to improve developer's lives by releasing quality code on GitHub and touring the world presenting the lessons we've learned. Read his blog at https://www.felixrieseberg.com/, follow him on twitter @felixrieseberg, and check out his work on github at https://github.com/felixrieseberg.