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.
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 committeeto 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
Anonymous
January 01, 2003
Don't bother http://code.google.com/chrome/chromeframe/Anonymous
January 01, 2003
Chome code is very useful huh?Anonymous
January 01, 2003
مشكورررررررر مشكوررررررررررررر رررررررررمشكورAnonymous
March 18, 2010
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 :))Anonymous
March 18, 2010
The comment has been removedAnonymous
March 18, 2010
The comment has been removedAnonymous
March 18, 2010
The comment has been removedAnonymous
March 18, 2010
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
Anonymous
March 18, 2010
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.Anonymous
March 18, 2010
It would be really great if DOM methods could become JS functions by the release of IE9.Anonymous
March 18, 2010
The comment has been removedAnonymous
March 18, 2010
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.Anonymous
March 18, 2010
@DanielHendrycks - I ran IE9 Preview through Sputnik, here are the results: Total: 5246 Succeeded: 4808 Failed: 438Anonymous
March 18, 2010
Btw don't misunderstand Pentium Dual Core as P4/Netburst. Pentium Dual Core is a 2008-09ish scaled down Core 2 Duo.Anonymous
March 18, 2010
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!Anonymous
March 18, 2010
Also IE9 fails 4 times as many Javascript errors as firefox 3.6 does.Anonymous
March 18, 2010
@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.Anonymous
March 18, 2010
@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.Anonymous
March 18, 2010
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?Anonymous
March 18, 2010
"we are also working with other JavaScript engine implementers in the ECMA Script committee to evolve JavaScript " Great great great !Anonymous
March 18, 2010
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?)
Anonymous
March 18, 2010
The comment has been removedAnonymous
March 18, 2010
@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.Anonymous
March 19, 2010
@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.Anonymous
March 19, 2010
@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.Anonymous
March 19, 2010
Browsers competing to make the fastest JavaScript engine is a good thing; especially when it involves the evolution of JavaScript. Good job IE9!Anonymous
March 19, 2010
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.Anonymous
March 19, 2010
@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?Anonymous
March 19, 2010
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.Anonymous
March 19, 2010
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.Anonymous
March 19, 2010
The comment has been removedAnonymous
March 19, 2010
The comment has been removedAnonymous
March 19, 2010
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.Anonymous
March 19, 2010
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.Anonymous
March 19, 2010
@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.Anonymous
March 19, 2010
>'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.Anonymous
March 19, 2010
Matthew Raymond, the text of your comment implies that you don't understand what the words "tracing" and "JIT" mean.Anonymous
March 19, 2010
@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.Anonymous
March 19, 2010
The comment has been removedAnonymous
March 19, 2010
Any plans to support geolocation?Anonymous
March 20, 2010
The IE team must have had a lecture from Steve Ballmer, this is too good to be true! XDD Keep up the great work!Anonymous
March 21, 2010
Great improvement with Javascript in Internet Explorer 9, Thanks!Anonymous
March 21, 2010
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.Anonymous
March 22, 2010
The comment has been removedAnonymous
March 22, 2010
Happy to see MS, finally had a look at improving IE. I just want to end writing IE specific code.Anonymous
March 22, 2010
@ 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.Anonymous
March 22, 2010
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!Anonymous
March 22, 2010
@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.Anonymous
March 22, 2010
@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 :-)Anonymous
March 23, 2010
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.Anonymous
March 23, 2010
@Stephen: I'm not sure I understand your suggestion; yes, IE9 does compile (JIT) JavaScript.Anonymous
March 23, 2010
The comment has been removedAnonymous
March 23, 2010
@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.Anonymous
March 25, 2010
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.Anonymous
March 25, 2010
@Jeff: IE developer tools have supported console.log since IE8. http://msdn.microsoft.com/en-us/library/dd565628%28VS.85%29.aspx#db_consoleAnonymous
March 31, 2010
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?Anonymous
March 31, 2010
felis: No, Microsoft isn't going to port IE9 to Win2k or WinXP. They removed the antipiracy check (WGA) shortly after they released ie7.