PDC10: Inside Internet Explorer Performance

Browser performance is a multi-dimensional topic: there are eleven different subsystems that taken together can affect the overall performance of a browser:


Different browsers may organize their internal implementation differently, but all these elements are important in their impact of the overall performance of a site.

An interesting lesson we can draw from the data we’ve measured in our research: site performance is not strongly correlated with the number of elements, CSS rules and amount of JavaScript code. Many people assume that JavaScript is the most significant indicator for browser performance, but the sample shows that it accounts for less than one-quarter of the overall client page load time. 

So the key lesson is that browser performance requires all the subsystems involved in page display to be optimized, rather than just the script subsystem. In IE9, we have rewritten a number of the eleven subsystems for maximum performance, and we’re going to cover a couple of these in greater detail.


Starting with JavaScript, IE9 introduces the new Chakra engine.

JavaScript engines can be placed on a continuum from a pure interpreter to a pure compiler. But picking one or the other end of the spectrum introduces compromises. IE9 is the first browser to do both: to build a full interpreter and a full compiler that are truly integrated. Because the compilation happens in parallel with the rendering, with every compiled function becoming available as soon as it is ready, the compiled code is available quickly to the page, while the interpreter can be used in the meantime.

This architecture makes sense because of the growth of multi-core client machines running Windows. Our data shows that the mean average number of cores on a Windows Vista or Windows 7 machine (i.e. machines that support the system requirements for IE9) is 2.46. In IE8, the ecosystem was not yet ready for this change, and so the interpreter there only takes advantage of a single core.

Another aspect of the change is the way the JavaScript engine integration has changed from IE8. In the past, COM was used as the bridge between the various language engines and the browser. This offered a lot of extensibility, but at an overhead for the primary language of the web. In IE9, we’ve built JavaScript directly into the browser as a first-class citizen, enabling the compiler and the browser engines to communicate directly via shared memory. We still support other language engines via the traditional COM mechanism.

One last interesting piece of data – we crawled the API usage of the top 7,200 websites worldwide, and discovered that the Pareto principle applies pretty accurately. Over 80% of the APIs in JavaScript are unused on 90% of the top sites. And surprisingly, indexOf() is the most commonly called function (not getElementById() as most people assume). This kind of data helped us optimize Chakra for real-world usage rather than synthetic benchmarks.


Hardware-accelerated Graphics

Every Windows computer has a GPU these days, and on Windows Vista or above, over 80% of machines have a graphics score of greater than 3.0. The GPU has become a highly-specialized computational engine optimized for graphics. Ten years ago, the CPU and GPU were roughly comparable in terms of the number of floating point operations per second each processor could deliver; today, the fastest GPUs in the world have a 10x advantage over the fastest CPUs in the world, delivering over a teraflop of computing power.

IE9 fully unlocks the GPU, using DirectX technologies like Direct2D and DirectWrite to accelerate everything in the browser: images, text, video, SVG, canvas, and CSS3. This has a dramatic impact on the performance of Internet Explorer 9 for visually-intensive websites, both compared to IE8 and indeed competitive browsers, as the following CPU usage graph shows while profiling one animation step in the Flying Images demo:


Other browsers are starting to add hardware acceleration – but no other browser available today adds hardware acceleration for more than a couple of technologies – for example, text, video, SVG remain CPU-bound on most other browsers.

[Session CD09 | presented by Jason Weber]