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.
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.
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.
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.
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]
(I would have posted this on Gaurav's web site, but he's neglected it severely it looks like).
Real world websites? Arrgh. Not that again. In all my tests, IE is faster than IE8, but not faster than Chrome, Safari, or FireFox. My super real world test is a large Ajax powered web application.
IE9 still is slower than the other major browser beta releases.
It's really too bad that Microsoft chooses to compete in a space that doesn't really need the competition anymore. Especially given that IE continues to be updated at a glacial pace. :(
Venting over. Need to go back and support and test multiple browsers, which we'll need to do forever. Long live the spirit of Silverlight and Flash (but not Java applets! Yuck!)!
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.
The line: "can also use the HTML script defer attribute to manually hint to the scripting engine that it shouldn’t execute a certain block of code." is a bit misleading. It doesn't tell the scripting engine not to execute a certain block of code-- it tells the scripting engine not to block the parser, instead executing the code later. Hence the name "defer".
Also worth mentioning that IE only supports defer and not the new ASYNC attribute.
Thanks Eric - you're quite right, of course; I meant to say "needn't execute this code _during the page load_". I'll update the article - appreciate your correction.