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:

image

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.

JavaScript

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.

image

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:

image

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]

Comments

  • Anonymous
    November 03, 2010
    Why comparing targeted JavaScript APIs again? Anyone knows thanks to "Marketing" that IE9 supports different APIs. Why not releasing an example - benchmark results - of modifying 200.000 Nodes in the DOM? Comparing it with Linux and other OS, of course! Sorry, but that GPU statement is really, really bad. On one hand you want to advertise with your massively "Direct2D and DirectX" usage - on the other hand this technology is proprietary. Why is OpenGL under Linux still about 60x faster than DirectX 10 on the same Hardware on Windows7? (Well, if you know how to use 3D-driver kernel modules correctly.) Think about it.

  • Anonymous
    November 03, 2010
    Hi Christoph, I appreciate your feedback (I think!). Although I can't help but think you're not entirely giving us a fair shake, given the comment on your site that our browser is "lazy, unsecure and not supporting any web standards". Really? Not supporting any standards? Even IE9? Would you give us any credit for anything we've done in this release by way of encouragement? :) Help me with some feedback: is modifying 200k DOM nodes something that you need to do for a site? Is it something you consider important for a web browser to support? And if you don't mind me asking, would this help you and the web more than (say) running Gmail or Facebook quickly? For the record, we're not too bad with synthetic benchmarks like WebKit's SunSpider - faster than Firefox and Safari, for instance. I'm interested to hear you say that OpenGL on Linux is 60x faster than DX10 on Windows 7 - is that a general statement, or is there a specific example? Incidentally, it's also worth noting that Firefox also uses DirectX for its hardware acceleration, and Chrome seems set to do the same when it adds hardware acceleration in the Chrome 9 timeframe. Thanks for taking the time to comment, Tim

  • Anonymous
    November 03, 2010
    The comment has been removed

  • Anonymous
    November 03, 2010
    (My old comment seems not to be inserted. I decided to split it.) Well, the OpenGL statement is an experience I made with two identical systems at work. The Linux kernel seems to run smoother and faster considering real-time isometric calculations. Most of the sites on the web are full of ads. That's no statement, that's reality. The web was unusable with the old Internet Explorer - that's why users switched their behaviour and switched to another browser. The only Plugin for Internet Explorer (I might know) is Adblock IE: http://adblockie.codeplex.com/ One of the seriously most important functions on the web is document.createElement - I made a quick n' dirty benchmark for it: sandbox.martens.ms/timer.html Linux / Turion X2 (2.0Ghz) with ATI Radeon 3200HD inside: about 257ms on Chromium My Core i5 system (2x 3.33Ghz Bloomfield) with its ATI HD 5770 takes about the five times more time. Only drivers, CC Generals and IE9 installed. This testing machine has no internet connection. Well, why this results? The system has more power, is faster, and is not running downstepped on 600Mhz? I think there's a huge difference considering used RAM or performance that influence the results. How long does it take on your hardware configuration? Does local caching really have an influence on speed? It shouldn't - in fact on any tested chromium system it's about 1ms slower than using global objects. No matter how often it is used. (Yup, I'm also working at chromium)

  • Anonymous
    November 03, 2010
    (Second part of first post) PS: I don't want to punish Internet Explorer 9. I think IE9 is the best IE that was ever built by Microsoft - considering that they also support new features in HTML5. But, that's quite a bit late. document.getElementsByClassName was first supported by Firefox 2 (!!!). Canvas was first supported in 2006 by Opera (well, beta...but IE9 is also beta). You are 4 years behind the time. The web could evolve so much faster if Internet Explorer had an Auto-Update and the users were forced to update their buggy, laggy, exploitable IE6. Any web developer that knows how to use CSS and XHTML will hate Internet Explorer if such things will happen again. I think the second time will be the last time. I don't want to work twice on a site - to test it with any browser - and test it with IE. That is horrible and frustrating. See the http://webslide.me play-code to see what I mean. Feature detection is also horrible, because IE7 seems to support more things than IE8. The window properties are different. Why not using window.event than window.Event - as ANY OTHER BROWSER ON THE WEB does? The web evolves as fast as the slowest Browser does. In my opinion you guys of the Internet Explorer development did an amazing work (seriously!) - but I think an Open Source engine would reach more users than a proprietary does. Trident would be a really cool engine with much potential. (But that's yours. I only wanted to write that for unknown reasons...) Well, that's it for now. Maybe I changed someone's mind with this post. Maybe not. (I'll start following this thread to hear other's opinions)