The New JavaScript Engine in Internet Explorer 9


The last five years have seen a remarkable series of advances in use of JavaScript on the Web. JavaScript has gone from a language for adding interactivity to a key driver for innovation on the Web. A new generation of applications such as Gmail and Office Web Applications use thousands (or hundreds of thousands) of lines of JavaScript to deliver functionality and complexity similar to traditional desktop applications. With the advent of AJAX and script libraries, nearly every new site today makes use of JavaScript. These changes have also pushed browsers and script engines to evolve rapidly to keep up with user and developer needs to have fast, responsive applications and sites.

The IE9 Platform Preview includes the first release of our new JavaScript engine, codenamed Chakra, which fundamentally changes the performance characteristics of JavaScript inside Internet Explorer 9. Chakra includes a new JavaScript compiler that compiles JavaScript source code into high-quality native machine code, a new interpreter for executing script on traditional web pages, and improvements to the JavaScript runtime and libraries.

In this post, we look at the engine we’re building in IE9, and our approach to script performance.

A Look Back at IE8

IE8, like other versions of IE before it, included a script interpreter for running JavaScript. Pure interpreters are usually adequate for traditional web pages with limited amounts of script, and we did a lot of work to improve performance of these sites in Internet Explorer 8, both in script as well as across the browser.

With IE9, we decided that we needed a better approach to building a script engine for the present and future demands of the Web. Clearly, the new engine had to be able to run traditional pages well. But the engine also needed to perform well on Web applications of today and the HTML5 application of tomorrow, as well as keep up with changes in the Web and in the devices used to browse it.

Benchmark Graphs and Traditional JavaScript Performance

In any discussion of JavaScript engine performance, one dimension always comes up first: that of pure execution speed. How fast does an engine get you from point A to point B in a JavaScript program? A number of well-known benchmarks have tried to represent JavaScript execution speed in different ways.

The most famous of these, the WebKit’s SunSpider benchmark, tries to measure execution of pure JavaScript in the engine. WebKit’s SunSpider benchmark performs tasks like string manipulation and mathematical operations. These test not only the ability of the engine to execute user code fast, but performance of runtime libraries such as regular expressions and arrays. Other benchmarks such as Dromaeo measure a broader set of scenarios, like common JavaScript language patterns, such as closures, and interaction with the HTML DOM.

As browsers have made their interpreters faster and added various forms of code generation, their scores on these benchmarks have improved. Over time, the relative gap between browsers on these benchmarks has narrowed significantly. In the work we’ve done for the IE9 Platform Preview, we have already substantially improved performance from IE8, since PDC, and will continue to do so as we work on IE9.

Bar graph of Webkit SunSpider Javascript Benchmark results

Going Beyond the Benchmarks

But performance of JavaScript in the browser is about much more than benchmarks. Browsers today need to deliver great performance across a broad spectrum of the Web from individual pages to complex Web applications, and on a variety of platforms. To run the Web well, a browser’s script engine must enable:

  • Great responsiveness in loading web pages with script. In our tests, we find that typical sites and applications use 10% to 30% of page load time running script. Code compilation and optimizations aren’t always effective, because the time needed to do this may offset the savings of running optimized code.
  • Responsive modern Web applications. Script-intensive sites such as Gmail and some of the IE9 TestDrive demos behave more like applications than static web pages, and can spend much as 30% to 90% of time doing operations on script.
  • An optimized experience on platforms from multi-core desktops to netbooks and mobile devices. User code in an HTML and JavaScript application is mostly single-threaded, but on today’s modern multi-core machines, browsers should find ways to use other cores intelligently to improve performance. At the same time, browsers must also run well on netbooks and low-power machines.

An engine should be able to easily adapt to changes in applications and patterns used on the Web, and to changes in hardware used to view the Web.

Qualities of the IE9 JavaScript Engine

So, let’s take a look at how we are building IE9 to meet these characteristics:

JavaScript Background Compilation: Many script engines today start with an optimized interpreter, and compile individual sections or methods into machine code to run faster. Others always compile JavaScript into machine code before running it, often compiling each method as it is needed. Both these approaches have to trade off quality or quantity of compiled code against execution speed. Generating high-quality code for today’s applications requires time to optimize the compiled code.

IE9 includes a fast interpreter for running pages quickly on startup. For compilation, we have a background code generator that compiles script code, and we push compiled methods back into the application. Because the code generator runs in the background, it can take advantage of today’s advanced multi-core machines and generate higher-quality code, while not blocking initial execution of the application.

Type Optimizations: One of the most important aspects of enabling performance on JavaScript is to create an efficient type system. The IE9 script engine uses many of the techniques common in modern dynamic language implementations, including type representation, polymorphic inline caching (also called type evolution or hidden classes), and efficient implementation of machine types.

Fast Interpreter: For pages where immediate execution in the interpreter is important, IE9 includes a new interpreter which uses a register-based layout, efficient opcode, and use of type optimizations.

Library Optimizations: The performance of JavaScript pages and applications depends heavily on key aspects of the script runtime library: strings, arrays, objects, and regular expressions. We are investing in these areas for IE9. These libraries require careful tuning for the real Web – one example is the execution of regular expressions. Most script engines today use compilation and optimization techniques to run regular expressions faster, and IE9 includes an improved regular expression implementation. In analyzing real world Web sites, we find a set of patterns used frequently, but we also find unique cases – for example, a site that creates hundreds of regular expressions and uses very few of them – we will continue to use this data to tune our regular expression implementation and other library features for IE9.

What Comes Next?

The steady rise of JavaScript performance in browsers leads to an obvious question: just how fast can JavaScript in the browser run? We know from measurements in the programming languages space that JavaScript is still limited in execution performance compared to C++ or statically typed languages. But code compilation, dynamic type inference and other innovations have enabled JavaScript to close that gap considerably.

As we work on IE9, we will continue to improve all facets of script performance: tuning our compiler, type system, libraries, and other runtime aspects such as memory management and DOM interoperability. We will also work on other dimensions of performance, such as memory usage and power consumption. The script engines of tomorrow will be judged how well they tune their performance across all these dimensions, across the entire Web.

We will also need the JavaScript language and runtime to evolve to meet the growing needs of developers and users. That’s why we are also working with other JavaScript engine implementers in the ECMA Script committee to evolve JavaScript in a responsible way that maintains compatibility with today’s Web, and meets the needs of tomorrow’s HTML5 applications.

Shanku Niyogi
General Manager, JavaScript team

Comments (57)

  1. Anonymous says:

    Chome code is very useful huh?

  2. Anonymous says:

    مشكورررررررر

    مشكوررررررررررررر

    رررررررررمشكور

  3. DanielHendrycks says:

    How does it do on Sputnik? http://sputnik.googlelabs.com/ I could not get IE9 to work. (Please post that "Where to post requests and questions" article soon :))

  4. David says:

    I’ve always wondered about that. There is just a limit that javascript cannot pass. The idea of interpreting while compiling for next time use is brilliant. But nothing can be done about the speed on the initial scripts. I imagine compilation/replace is relatively fast and transparent.

    This is one the reasons why SVG+Javascript cannot replace Flash/Silverlight. Speedwise compiled code will always be uncontested.

  5. Tech says:

    Err, David, you understand that Flash uses ECMAScript (basically JavaScript) and Silverlight uses MSIL, right? Neither of those forms of code are native code until they are JIT compiled on the client side.

  6. Francis Hemsher says:

    As this evolves, please delineate the best way to posture/call Javascript files to take full advantage of this technology.

    e.g.

    1) place all .js file calls in <head>?

    2) call .js file ‘on demand’ ?

    3) place .js files in their iframe object ?

    4) etc…

  7. William J. Edney says:

    Shanku –

    This is all *awesome* news that I’ve been waiting 10 years to hear – finally modern optimization techniques for JavaScript in IE.

    BTW, Lars Bak (the main guy behind the V8 work at Google and one of the main people in the "Self" project at Sun in the early 1990s where many of these techniques were developed) has claimed that the Self virtual machine achieved half the speed of optimized C. I would imagine his goal for V8 at Google is the same :-).

    So keep the speed competition going!

    Please pass along my sincere thanks to your entire team!

    Cheers,

    – Bill

  8. mitchum says:

    All of this sounds awesome – does this mean that simple things like:

    window.prompt(statement,default);

    will actually work properly in IE9?

    e.g. with the chrome fixed, the position fixed, the multiline content fixed, the lack of stretching to fit fixed, and finally the button placement fixed?

    http://webbugtrack.blogspot.com/2007/10/bug-109-javascript-prompt-in-ie-how-did.html

    Internet Explorer can’t be taken seriously until basic issues like this are fixed.

  9. Grah says:

    It would be really great if DOM methods could become JS functions by the release of IE9.

  10. Will Peavy says:

    Chakra is the some of the best news the web development world has seen in a while. Glad MS is now in the JS speed race!

  11. Tester says:

    I tried running the SunSpider benchmark on IE9 in Windows 7 on my Pentium Dual core laptop but I got a ~3500 ms latency!! But on my faster C2D desktop, I am getting a respectable score. If JavaScript performance is going to be so sensitive to processing power of the cores, the "fast" engine is worthless to me. Anandtech’s review of IE9 makes the same point. This discrepancy should not exist.

    Btw, XP not supported – very bad decision. Please reconsider. Without WinXP, your brand new browser is going to be so limited as not everyone uses IE even on Vista or Windows 7. IE9 marketshare will never exceed any other browser’s most recent version.

  12. Will Peavy says:

    @DanielHendrycks –

    I ran IE9 Preview through Sputnik, here are the results:

    Total: 5246

    Succeeded: 4808

    Failed: 438

  13. Tester says:

    Btw don’t misunderstand Pentium Dual Core as P4/Netburst. Pentium Dual Core is a 2008-09ish scaled down Core 2 Duo.

  14. penubag says:

    Why in the world is IE9 focusing on SVG? There are still many many flaws with IE9 with respects to JavaScript and HTML5.

    I’ll tell you why the IE team is focusing on SVG, it’s because they want to shy away all the negative aura around IE by pointing out the flaws of other browsers.

    PLEASE IE TEAM, FOCUS ON FEATURES THAT PEOPLE ACTUALLY USE!

  15. penubag says:

    Also IE9 fails 4 times as many Javascript errors as firefox 3.6 does.

  16. Stifu says:

    @penubag: developers here and elsewhere have been tirelessly asking for SVG support in IE for several years… That’s why IE9 is focusing on SVG.

  17. wechrome says:

    @Tester,

    Javascript benchmarks of course depend on the CPU speed like any benchmarks out there. It’s not an IE-only problem, you’ll get better result on a faster PC, while worse result on a slower PC.

    You should compare the IE9 result with other browser’s result on the same system, not comparing IE9 result across different systems, that’ll become a CPU benchmark, not a browser benchmark.

    So you should try run something like Firefox 3.6 on your Pentium Dual Core and see how Firefox scores compared to IE9’s ~3500ms score.

  18. Mitch 74 says:

    Javascript speed is good, but something troubles me in the Platform preview.

    Error 15 in Acid3, text file ran script (security bug).

    Is this error caused by the lack of ‘zones’ support or something in the platform preview?

  19. Jean-Philippe Martin says:

    "we are also working with other JavaScript engine implementers in the ECMA Script committee to evolve JavaScript "

    Great great great !

  20. says:

    Thank you for the overview of the new JS engine.  It looks very promising.

    Some questions:

    * Is this new JS engine used only in IE, or will WSH (wscript.exe/cscript.exe) automatically use it, too?

    * Which ECMAScript language version are you aiming for?

    * Do you have guidelines regarding patterns that should still be avoided?  (e.g. are live lists of DOM elements still slow?)

  21. Matthew Raymond says:

    Note that, for Firefox, the graph on this article is already out of date. Mozilla Minefield 3.7a4pre (the latest nightly build of Firefox) beats the IE9 Test Drive on SunSpider by about 12 milliseconds.

    Furthermore, it’s a known fact that SunSpider favors JavaScript engines that do less efficient (but faster) JIT compilation rather than the super efficient (but more time-consuming) "tracing" method used by Firefox’s TraceMonkey. Mozilla’s JaegerMonkey engine will WebKit JIT compiler code to fix this issue by using the faster, less efficient compiled code instead of an interpreter while it waits for the tracing to be completed. This results in performance equal to other browsers when tracing either fails or takes to long, but far superior performance when tracing is successful, yielding best-of-both-worlds performance. It will be interesting to see how the release version of IE9 does against the next major release of Firefox…

  22. alpha123 says:

    @Will Peavy:

    So it actually finished? I tried spudnik with IE8 on a Win7 Home Premium 64-bit Core 2 Quad @ 2.50gHz and 6GB RAM….. and it crashed half way through :-P.

  23. Will Peavy says:

    @alpha123

    IE9 Preview stalled a number of times. You can get out of some stalls by pressing pause/resume. Other times, you have to refresh the page (or sometimes restart the browser) – in which case, Sputnik will pick up where you left off before the refresh/restart.

  24. EricLaw [MSFT] says:

    @Mitch 74: Test 15 tests whether or not the browser cares about the MIME type of the file pointed to by the SRC attribute of a SCRIPT tag. Internet Explorer 6/7/8 do not check the MIME type of the response when looking at the response to a SCRIPT SRC download.

  25. Vedetta says:

    Browsers competing to make the fastest JavaScript engine is a good thing; especially when it involves the evolution of JavaScript. Good job IE9!

  26. Wow. I’m impressed, hopefully, there’ll be a day where I don’t have to constantly disable IE and install Firefox for my clients.

  27. Mitch 74 says:

    @EricLaw: IE 8- don’t check script src MIME types, indeed – but it seems IE 9 doesn’t either, which is what bothers me.

    I thought IE 8 implemented stricter MIME type enforcing, and IE 9 should do it even more. After all, the ‘type’ parameter in a script tag is here for that, isn’t it?

    Oh, I forgot to check: will IE now accept ‘application/ecmascript’ and other valid, non-deprecated types for said script types, as per RFC 4329?

  28. Bashism says:

    What is so special about IE 9 that the most powerful software company in the world cannot get it to run in XP.

    Do Chrome, Opera, Safari ignore XP? Tiny companies like Opera and Mozilla are able to support XP.

    There is only one reason: Force people to upgrade to Windows 7 by starving XP.

    Artificially excluding XP is criminal monopolistic behavior.

  29. Clue says:

    bashism, while you’re obviously not a lawyer, i’m wondering how you could possibly come to the conclusion that decreasing the size of your market is a characteristic of a monopoly. You don’t maintain a monopoly by providing a competitive advantage to your competitors.

    You’re also forgetting that despite the fact that XP’s support lifetime was extended several times, it’s still going out of support very soon.

  30. EricLaw [MSFT] says:

    @Mitch: Ah. The failure text is a bit ambiguous and led me astray. Test 15 is not about whether or not the SCRIPT tag cares about the MIME-type of the SRC response, it’s actually about whether or not text/plain can be sniffed to HTML when loaded in an IFRAME.

    IE8 reduced the number of scenarios in which IE would sniff content to determine its MIME type, but this restriction applies by default only to responses which claim to be of any image/* MIME type. For text/plain or other types, the server can opt-out of sniffing via the x-Content-Type-Options: nosniff directive.

    Because the ACID server does not send that directive, IE sniffs the HTML and fails the test. In order to pass test #15, IE would have to stop sniffing text/plain delivered documents to HTML.

    Other MIME-type trivia: in Strict mode, browsers won’t apply a stylesheet sent as text/plain (www.enhanceie.com/test/css/strict.htm), but will apply it if the document is in Quirks mode.  In contrast, regardless of mode, Opera, Firefox, Safari, IE, and Chrome will run script from a text/plain file returned in response to a SCRIPT SRC (www.enhanceie.com/test/js/).

    Unlike in earlier versions, the IE9 Developer Preview permits you to specify the type attribute with value "application/ecmascript" in your SCRIPT tag.

  31. Tester says:

    @wechrome, obviously no one’s foolish enough to compare scores on a fast system with one on a slower. Other browsers have scores in the same range but IE9’s sunspider score is varying greatly by PCs. Other browsers speed up Javascript execution primarily by making the engine more efficient whereas the IE team seems to have taken the router of making it far more sensitive to processor power.

  32. Always the one to break the rules says:

    I agree with bashism. When all other browser companies are supporting XP, Microsoft makes it a requirement to use Direct2D just to cut XP compatibility and sell more Windows 7 copies. If they were genuinely concerned about progressing the web, they would support XP just like all other browser vendors. IE9, a free upgrade for 20% of the web and yet lacking behind in standards compared to other browsers. Even if page rendering speeds are improved, the chrome of the browser, tab loading speed, memory consumption are all the slowest for IE. What improvements is the IE team doing to address these? Chrome opens in the blink of an eye and does not slow down when 5 windows each with 10 tabs are open.

  33. Matt says:

    tester, you should have coffee with a computer-savvy friend and have them explain to you why your post just doesn’t make sense.

    JavaScript engines get faster as they generate more efficient code. As code is more efficient, it runs faster– on all processors.

  34. Mitch 74 says:

    @EricLaw: thank you for those answers. Supporting ‘application/ecmascript’ will make it much, much easier to target ‘proper’ javascript to modern browsers. I knew about the ‘src’ problem (compatibility reasons), but the test is successful in other browsers, meaning that IE 9 could be more strict in its sniffing – if at all.

    x-Content-type is, in essence, not an answer, as it’s not default, and a proprietary header. It’s a good way to secure your server, but if your host doesn’t allow you to define custom headers and doesn’t do it either, then it’s useless.

    It would be nice if IE 9, in its ‘best’ render mode, didn’t try to sniff around at all – X-UA-Compatible would be enough of a compatibility override then.

    A CSS style sheet is less troublesome, as CSS is not (except in IE 7-, with CSS expressions) supposed to contain executable code – although processing ‘text/plain’ CSS is not correct, it’s also very low risk (again, except in IE 7-) as it contains no executable code (at best, you can crash a CSS parser). Doing so with scripts is much more risky.

  35. EricLaw [MSFT] says:

    >’text/plain’ CSS is not correct, it’s also very low risk

    There’s a non-trivial threat here, but it’s a different type of risk.

    There are many interesting threats in the web application security model.

  36. Andrew says:

    Matthew Raymond, the text of your comment implies that you don’t understand what the words "tracing" and "JIT" mean.

  37. Matthew Raymond says:

    @Andrew, to clarify, by "tracing" I’m referring to trace-tree compilation (as opposed to the logging of debug messages, which is probably what you’re thinking). See the following articles:

    http://www.ics.uci.edu/~franz/Site/pubs-pdf/ICS-TR-06-16.pdf

    http://www.bailopan.net/blog/?p=683

    Generally, the idea is that Firefox 3.6 compiles based on code loops that may span multiple methods, while browsers like Chrome compile entire methods. When Firefox can generate a tree that describes the structure of the loop, it can compile machine code that’s far more efficient than method compilation, but when it can’t generate the tree, it has to fall back to using an interpreter, resulting in a significant performance hit. By using machine code generated by WebKit’s Nitro JIT instead of using the interpreter, they’ve been able 30% better performance without optimization of the code.

    I’m not sure in what context you object to my use of "Just-In-Time" (JIT). It’s usually applied to compilation of bytecodes, but my understanding is the the actual JavaScript code is converted into bytecodes that are sent to either a compiler or the interpreter.

  38. jim d says:

    What version of JavaScript are you supporting in IE9?  My tests seem to indicate that it only goes as high as JavaScript 1.3, while other browsers are up to at least 1.7.  

    JavaScript 1.3  is *twelve* years old. I was hoping for something newer.

  39. Any plans to support geolocation?

  40. :3 says:

    The IE team must have had a lecture from Steve Ballmer, this is too good to be true! XDD

    Keep up the great work!

  41. Kiran says:

    Great improvement with Javascript in Internet Explorer 9, Thanks!

  42. Rocky Madden says:

    Wonderful news and great job on getting this in place. Looking back at this point in browser history, it will likely be seen as the biggest leaps in performance. Nice to have some competition to keep pushing each other to the top of their game.

  43. Victor says:

    Still same incompatibility with IE9 preview as with all the previous IE versions.

    Only IE refuses to work.

    Will there be attempts made to make IE9 compatible with the rest of the implementations or will we still be forced to develop hacks and separate streams to allow IE users to use advanced websites?

    I saw no mention of this, only of execution speed which is not entirely useful if it fails to execute code that works fine with every other engine.

  44. Happy to see MS, finally had a look at improving IE.

    I just want to end writing IE specific code.

  45. Victor says:

    @ Arun… I do not think they stressed compatibility as the main issue. MS IE team is still somewhat stuck in the IE6 mindset so all we are getting is incrementally visually more polished versions of IE6.

    The performance gains quoted for each new version are against the present, not against the future performance where the alternative browsers will be by the time even IE9 reaches us.

    Do not forget that even the still very new and according to MS "current" IE8 does not support CSS3 or curent javascript versions – a glorious example of the mentioned bad IE6 mindset.

    I’d love to be wrong…and so would everyone else outside of MS.

  46. The CLR/DLR is good at spitting out very optimised code – is this JS engine written on top of that?  Or is it created separately?  Because being able to have JS running as a .Net language would be fantastic!

  47. ieblog says:

    @Victor: What specifically have you found to be incompatible?

    @Andrew: No, the new JavaScript engine is not based on the CLR/DLR, although some of the same engineeers are involved, and obviously we’ve learned from the CLR/DLR implementations. You can already run JavaScript in .NET (http://en.wikipedia.org/wiki/JScript_.NET) and you can already compile C# to JavaScript (http://projects.nikhilk.net/ScriptSharp)

    @Jim D: What JavaScript constructs are you trying to use that don’t work?

    @MatthewRaymond: Typically "JIT" refers to the compilation of byte-code into native machine code. Tracing is one of a number of techniques that implementors have used to decide whether or not a given block of byte-code should be so compiled.

  48. Victor says:

    @ieblog

    Thank you for reading adn replying to the comments…there may still be hope :-)

    To be honest, I do not know what is incompatible. A script fails with all versions of IE, but causes no problems or bug flags under Firefox, Chrome, or Opera.

    I can share more information with you if you would like me to email you the site link using the Email form on this blog.

    This type of error is unfortnuately actually not rare with various incarnations of IE, but it may be specific enough so that it can be fixed for IE9.

    V.

    …oh I just got an email from you. I am truly blown away. I sent a reply – more constructive this time :-)

  49. Stephen says:

    It is nice that javascript engine parses faster, but what about caching? iirc it doesn’t JIT. But does it cache? I suggest investigating caching parsed jscript in a serialized format.

  50. EricLaw [MSFT] says:

    @Stephen: I’m not sure I understand your suggestion; yes, IE9 does compile (JIT) JavaScript.

  51. Victor says:

    @ieblog and @EricLaw

    OK I resolved the problem with our shop site. It now works with all IE versions (up to a point, but it is as least functional).

    The feature of our shop engine that IE cannot handle is to do with "hooks" module which is used to modify smarty templates without having to hack the original code. Hooks allow software upgrades to occur without having to re-do all the customisation changes every time.

    Now with our "fix" for IE compatibility, we had to disable the hooks module and are back to making additional hacks to the code. This is of course rather tragic as IE is forcing us to abandon good development practice (reminder, the shop site works with the hooks module enabled with Firefox, Chrome and Opera, only IE does not) just to accommodate the proportionally large number of various version IE users that visit our new shop.

    Thus, our shop code is now full of hacks and separate IE streams as each IE version fails at one point or the other. We now have IE6 path and IE7 hacks and now IE8/9/etc. hack that adds significant overhead to us since we will now need to manually modify the shop engine code in order to implement any customisations.

    Therefore, as per my earlier exasparated email, and the followup, nothing would make me and other web developers large and small happier than if IE development team prioritised compatibility/interoperability above all else.

    Performance metrics are nice for press releases, PR and development team KPIs, but are irellevant if IEx cannot run real life applications corectly (again, correct = all other tested engines work with the same code).

    Remember that presumed new IE team mantra: "don’t break the web." That would be very nice.

  52. EricLaw [MSFT] says:

    @Victor: We’ve got some folks who would be happy to take a look at what technology your "hooks" module is actually using– I’m not sure what a "smarty template" is.

    As I mentioned previously, it’s likely that the problem has nothing to do with the script engine itself.

  53. Jeff says:

    are there going to be some decent debugging tools for IE9? at least give a console for logging errors to. i’m tired of putting alert boxes up for IE.

  54. Felis says:

    This is great news!

    Keep it going IE Team!

    The next step is to let everyone with NT 5+ core windows (no matter how they get their copy) enjoy the seems one of the best IE version ever – the ver. 9  – for everyone’s sake!

    Please?

  55. Matt says:

    felis: No, Microsoft isn’t going to port IE9 to Win2k or WinXP.

    They removed the antipiracy check (WGA) shortly after they released ie7.