PDC10: Unlocking the JavaScript Opportunity with IE9

Websites are exploding in the quantity of interactivity they contain: over the last few years, they have become fully-fledged applications with functionality and complexity at a level that was previously limited to desktop applications.

Scripting Engine Design Challenges

Prior to IE9, the JavaScript engine was built from an original design optimized for many different uses beyond IE (for example, Windows Scripting Host). As a result, it was designed as a component that could be dropped into different applications, with COM used to marshal data between the engine and its host application. COM-based marshaling added an overhead of 10-20% to the overall page load time, due to all the required boxing and unboxing.

Today’s engine needs to be optimized for a different set of scenarios: the browser is now by far the most prevalent usage scenario for our JavaScript engine, and these days there’s no question about which scripting language is dominant, so the browser has a far reduced need for extensibility.

On top of the architectural changes, we enable compilation to native machine instructions to provide a performance boost at execution time, particularly with large codebases. (See also the session on IE9 performance by Jason Weber for further details on this.)


Chakra offers a hybrid approach, with both interpreter and designer built into the design. By having the interpreter running on the UI thread, we can stay responsive; but we still get the benefits of compilation through a background thread. It’s not a simple task, however – challenges we had to solve included keeping a tight memory footprint and optimizing compilation for real-world patterns.

The diagram below shows an architectural view of Chakra:


We don’t compile all code, instead, we keep a compilation queue; we speculatively compile some quantity of code, but use heuristics to prioritize the queue based on most frequently called functions, the size of the function etc.

We’ve spent time validating the design of Chakra against real-world websites. For page load times, we’re seeing an average of 14-15% improvement performance improvement – not just for the engine but across the entire stack.

IE9 introduces a new type system for JavaScript. Dynamic languages in particular need an efficient type system – types are created at runtime and multiple objects often have the same set of property. By providing a type evolution model that shares types, we can be much more efficient in these scenarios.

One important property-based technique introduced in IE9 is inline caching. Since property access is the most widely used operation and the same key of a key-value pair is often accessed multiple times on a call site, we simply cache the value for each call site.

The old JavaScript engine used to only work with 8-byte representations of numbers, even if they required less precision. Chakra introduces tagged integer support – with 31-bit numbers (a flag is used for the 32nd bit as an indicator); we go to a full 8-byte representation automatically if the number grows to require more then 31 bits of precision.

In a similar vein to tagged integer support, Chakra avoids conversion to UTF-16 where possible, retaining strings in UTF-8. This results in a gain of about 300-400K in working set and 3-4% load size wins for complex apps.

One piece of research which was particularly helpful in planning was done by Microsoft Research. The JSMeter project was conducted to measure real-world usage of JavaScript on top sites. One specific insight related to the percentage of code that sites load that is actually executed. For most large sites (including Amazon, Bing, CNN, eBay, Facebook etc.) only 40% of the code fetched is executed. Learning from this, Chakra uses a deferred parser, which reduces working set and increasing load times. (Note that you can also use the HTML <script defer> attribute to manually hint to the scripting engine that it needn’t execute a certain block of code during page loading.)

New ECMAScript 5 Features

The relatively recent release of ECMAScript 5 introduces a number of new keywords and language features. For backward-compatibility reasons, these features are only enabled in IE9 when IE9 Standards Mode is enabled (by default for external sites unless an older compatibility mode has been selected).

There is a very detailed blog post on the ES5 features added to Internet Explorer 9 on the IE engineering blog (also see this update).

You can see a fun test of browser support for various DOM capabilities on the IE Test Drive site.

[Session CD08 | presented by Gaurav Seth ]