Firefox for Mobile has been getting excellent reviews for features and functions. We also have good numbers for JS performance, an important component of building compelling web applications on mobile.

Mobile Sunspider Performance – Click for a Larger Version.

I also wrote up a big post that goes over some of the new web developer features in this beta in the web-tech blog. There’s a pile of stuff in there that most people don’t even know about, so taking the time to look through the list even if you’re not going to download the beta is worth it. We’ve got some neat stuff coming up for 3.1.

Beta 2 will feature some more user-visible features and a pile of new web developer features as well. So much good stuff coming down the pipe.

Enjoy!

In terms of claims some members of the V8 team have been bragging a little bit about how V8 is “many times faster” than TraceMonkey. In fact, some guarantees may have been made.

Based on the data above, we’re running about 20% faster than V8 on SunSpider. While I’m sure there will be changes to each of the engines in the coming months I think that the claim that “many times faster” is ludicrous on its face and should be tempered by actual data. [ Note that the Google test is recursion heavy, something we're adding to TraceMonkey right now. This explains the gap on that one type of test. See Brendan's post above or John's post below for more details. ]

It’s also important to realize another fact. Google has had a small army of people working on the V8 engine for two whole earth years. We’re about 60 days into TraceMonkey and we’re already starting to match the performance characteristics of V8. As Brendan put it:

What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more “headroom” than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we’ll find out over the next weeks and months, and so will you all.

If you want data across browsers you should look at this post from John Resig that contains some graphics that give relative performance of various browsers including Safari, Firefox 3.0.1, IE, etc. His overview is great and gives a much wider view of relative browser performance.

Also as a side note because I have your attention. There are some bizarre and incorrect claims made in the comic about garbage collection. Brendan puts things right as a comment in John’s post:

@Ben: Chrome has a nice GC: exact rooting, generational with copying. Single-threaded, too (not an option for SpiderMonkey, which is used in AT&T 1-800-555-1212 and 411 AVR massively multi-threaded services built by tellme.com, now owned by Microsoft!). It definitely helps cut down on pauses and keep memory use flatter.

The Chrome comic book did have one piece of misinformation, though: it said other browsers’ engines use conservative GC, and have false positive problems because they can’t distinguish random integers from pointers into the heap. This is not true of Firefox, IE, or Opera.

We do live in interesting times.

• Brendan Eich: TraceMonkey: JavaScript Lightspeed
• John Resig: TraceMonkey
• Mike Schroepfer: What can you do when your browser is 7 times faster?
• Mike Shaver: The birth of a faster monkey
• Ryan Paul: Firefox to get massive JavaScript performance boost

The heart of the story is that we’re seeing performance increases on benchmarks of anywhere from 1.8x to 37.5x depending on the benchmark used.

But the thing that most people don’t realize is that you can take advantage of the work that we’re doing in SpiderMonkey in your program as an embedded JS interpreter. It’s a pretty tiny engine, has a relatively stable API and even has useful documentation. John’s post contains four commands that you can use to build the engine. In fact, it’s so short, I’ll re-paste it here:

hg clone http://hg.mozilla.org/tracemonkey/
cd tracemonkey/js/src
make -f Makefile.ref BUILD_OPT=1
Linux_All_OPT.OBJ/js -j

And you’re in a command line JS interpreter. No fuss, no muss.

Many people don’t realize it but most of what people think of as JavaScript is the browser API, not the JavaScript language. To quote from the JavaScript C Engine Embedder’s Guide:

The word JavaScript may bring to mind features such as event handlers (like onclick), DOM objects, window.open, and XMLHttpRequest. But in Mozilla, all of these features are actually provided by other components, not the SpiderMonkey engine itself. SpiderMonkey provides a few core JavaScript data types—numbers, strings, Arrays, Objects, and so on—and a few methods, such as Array.push. It also makes it easy for each application to expose some of its own objects and functions to JavaScript code. Browsers expose DOM objects. Your application will expose objects that are relevant for the kind of scripts you want to write. It is up to the application developer to decide what objects and methods are exposed to scripts.

The Embedder’s Guide does contain a lot of good information you can use to get started embedding SpiderMonkey into your application. It’s worth a read if you’re looking for a decent scripting engine for your app.