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

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 ]

Comments

• Anonymous
  November 01, 2010
  The comment has been removed

• Anonymous
  November 01, 2010
  Aaron, would love to see a reproducible test. The purpose of talking about real-world websites is that it's a better comparison than synthetic benchmarks that are easy to optimize for but don't exercise the browser in the same way as a typical site. Nevertheless, the latest public IE build is faster on the JavaScript WebKit SunSpider benchmark than the most recent betas from Firefox and Safari, and is pretty close to the others. I'm surprised that you're keen that rather than adopting open standards, you want everyone to coalesce around a single browser engine - it's an interesting viewpoint, but I think most people involved in the standards process would say that it would greatly stifle innovation and leave the HTML specification without any purpose other than to document WebKit. Presumably you're asking Mozilla to switch Firefox away from Gecko also? Do you really feel the web doesn't need competition anymore? It's an unusual viewpoint: I wonder who you would anoint as the 'winner'? Thank you for sharing your views. Best wishes, Tim

• Anonymous
  November 02, 2010
  The comment has been removed

• Anonymous
  November 02, 2010
  The comment has been removed

• Anonymous
  November 15, 2010
  Jeeze, Louise, with IE9 JavaScript is getting really complicated. I hope that my JavaScript artificial intelligence at www.scn.org/.../AiMind.html will continue to operate within IE9 and all future MSIE releases. I tried to code the AI Mind in Netscape Navigator years ago, but only Microsoft Internet Explorer would let me create the artificial intelligence in the way that I wanted. Now each new MSIE release fills me with trepidation, but so far, so good.