about:mozilla » JavaScript

TraceMonkey and Firefox Mobile

deb — Mon, 15 Sep 2008 15:12:30 +0000

Over the past few weeks, Vladimir Vukićević has been working on getting TraceMonkey working on the ARM architecture which is frequently used in mobile and handheld devices. “[M]obile and handheld platforms are going to quickly become consumers of the full web, and core performance gains will often yeild much more significant user-perceptible performance improvements. The result of all this work will be a richer web experience on mobile and embedded devices, by allowing those users to take advantage of modern web applications that do much of their work on the browser instead of server side.” Vlad’s TraceMonkey work will be available for testing in the next alpha release of Fennec (the code name for Firefox Mobile) by enabling a configuration setting the same way testers can enable TraceMonkey in Firefox nightly builds. For more information, including a host of technical details, see Vlad’s weblog.

JavaScript benchmark quality

deb — Fri, 12 Sep 2008 14:29:30 +0000

While JavaScript engine performance has been undergoing a renaissance, JavaScript benchmark tests haven’t been keeping pace, and aren’t adapting well to the rapid performance increases we’ve been seeing. John Resig has put together a post analysing the problem, looking at three different benchmark suites — SunSpider, Dromaeo, and V8 Benchmark — and what they are doing to counter-act the problem of error levels increasing as browsers are able to run the tests more and more quickly. It’s a detailed and interesting peek into the world of JavaScript benchmarking, and you can read John’s full post on his weblog.

Tracing the Web: Andreas Gal on the new TraceMonkey JavaScript engine

deb — Mon, 08 Sep 2008 14:30:21 +0000

For the past two months Andreas Gal has been part of the Mozilla team working on a just-in-time (JIT) compiler for the JavaScript engine in Firefox. On August 22nd the project (code named “TraceMonkey”) was added to the main Firefox development code base.

Andreas writes, “TraceMonkey is a trace-based JIT compiler and it pushes the envelope on JavaScript performance. On average, we speed up Apple’s popular SunSpider benchmarks by a factor of 4.6 over the last release of Firefox. For the SunSpider ubench suite, which focuses on core JavaScript language features, we achieve a speedup of 22x. Whichever metric you chose to apply, Firefox now has the fastest JavaScript engine in the world.” Andreas’ post goes on to discuss the concepts and background behind TraceMonkey in detail, including dynamic compilation with traces, trace trees and nested trace trees, and type specialization. You can read the full article at Andreas’ weblog.

TraceMonkey vs. V8: JavaScript performance results

deb — Fri, 05 Sep 2008 15:07:30 +0000

JavaScript is an increasingly vital aspect of web browser performance since many web applications (web mail, online word processors, and so forth) rely heavily on complex JavaScript programs for their core functionality. In the past year, JavaScript performance has gone through somewhat of a renaissance, with massive strides being made by JavaScript developers working on several different projects. The two most recent developments come from Mozilla and Google — Mozilla’s new TraceMonkey engine that is part of Firefox 3.1 development, and Google’s new V8 engine that is part of the Google Chrome beta.

Brendan Eich has run some performance tests, and has posted the results of the head-to-head showdown in which he pitted the engines against each other using the SunSpider test suite on Windows XP and Windows Vista (Google Chrome is not currently available for either Mac or Linux). Brendan writes, “[TraceMonkey] win[s] by 1.28x and 1.19x respectively,” but adds that SunSpider is “one popular yet arguably non-representative benchmark suite.” He finishes by pointing out that “this contest is not a playoff where each contending VM is eliminated at any given hype-event point,” going on to sketch the rough outlines of the approach the team is taking to further improve TraceMonkey performance.

Brendan’s complete test results and commentary are available on his weblog. Further information about TraceMonkey and JavaScript performance is available through web posts by Mike Shaver, Andreas Gal, and John Resig.

JavaScript performance improvements coming for Firefox 3.1

deb — Mon, 25 Aug 2008 15:50:52 +0000

Mike Shaver writes, “Over the past year, JavaScript performance on the Web has undergone a striking revolution. Virtually every browser has improved its engine to produce significant gains in execution speed; Firefox 3 is about 3 times faster than Firefox 2 in various JavaScript benchmarks, for example. We’re not done. In addition to continuing to work on our existing JavaScript interpreter, we’re also looking farther into the future of JS performance. Yesterday we landed TraceMonkey in the Firefox 3.1 development tree, configured off by default. We have bugs to fix, and enormous number of optimizations still to choose from, but we’re charging full speed ahead on the work we need to do for this to be part of Firefox 3.1″. Early tests are showing significant speed and performance improvements, and all of this has been blogged about at length by the various people involved:

TraceMonkey: JavaScript Lightspeed (Brendan Eich)
Tracing the Web (Andreas Gal)
The Birth of a Faster Monkey (Mike Shaver)
Great performance improvements coming for Firefox 3.1 (Mike Schroepfer)
TraceMonkey (John Resig)

ECMAScript Harmony: JavaScript evolution in action

deb — Mon, 18 Aug 2008 19:14:35 +0000

Recent events related to ECMAScript — the specification that guides the development of JavaScript — have generated an unusual amount of buzz and press coverage. The crux of the matter is this: the ECMAScript 4 specification has been under development for quite some time. Those involved (primarily from Adobe, Mozilla, Opera, and Google) agreed upon a set of features they thought should be implemented and created a specification around that framework.

Other people (primarily from Microsoft and Yahoo) disagreed with how much of the ES4 specification should actually be implemented. Within the framework of the ECMAScript 3.1 activity, they advocated select changes to ECMAScript 3, and were averse to some of the syntax changes in ES4. Almost inevitably, this split lead to a situation where the ECMAScript 3.1 group wanted to add changes that would impact the development of ECMAScript 4, resulting in a clash between the groups that has stretched out over the past year.

Discussion between these two groups finally came to an amicable conclusion earlier this month at the July 2008 Oslo meeting, however, resulting in a cooperative refocusing on simplicity and pragmatic language additions. This collective effort will work to improve the existing ECMAScript 3.1 specification while, simultaneously, working on a new successor specification with the moniker “ECMAScript Harmony” that will include more significant language additions.

These developments have been covered extensively by other bloggers and podcasters, where you can get the full story: John Resig on ECMAScript Harmony, Arun Ranganathan’s Thoughts on Harmony and Evolution, and the Open Web Podcast on ECMAScript Harmony.