Kevin’s blog

Surfin’ Safari - Blog Archive » Announcing SquirrelFish

As many of you know, I’m a big fan of the Safari web browser on the Mac platform¹ and others of you will know that in fact I use the nightly builds of the WebKit rendering engine rather than the official supported releases from Apple, as the nightlies tend to have newer functionality for only a very small stability hit.² Well the latest update has got me very excited…

I should probably digress a little about web browser design before I continue. If you’re familiar with how a browser is put together, feel free to skip the next two paragraphs.

In very basic terms, a web browser is a nice user interface to one or more rendering engines which decide how to put a page together dependent on its content. The user interface is the windows and icons that direct the rendering engine to whichever page the user wishes to view, whereas the engine does all of the layout and any processing. Because of this fact, many web browsers with different user interfaces share the same rendering engine(s). For example the Gecko engine used in Firefox can also be found in Camino, Flock and SeaMonkey; the Webkit engine used in Safari is also used by OmniWeb. One less frequently utilised consequence of this partnership is that it is possible to use the same user interface with a different rendering engine.³

Now, since the web uses a number of different technologies to deliver content it is usual to find more than one engine, each specialised for a specific content type; say one for HTML-like content, one for JavaScript, one for Flash, etc. We’re all relatively used to the idea of ‘upgrading to the latest version of Flash’ where the engine for Flash content is swapped out for a newer version. This is usually a painless process because the Flash component is almost always loaded as a plugin — an optional component that’s easily added or removed. However because the HTML and JavaScript engines are the cores of a web browser they are usually much more integrated⁴ and are not so easily swapped out, so engine upgrades are usually not performed separately to full application upgrades. Most engines are undergoing continual development however, so updating your browser core(s) can introduce new features and performance benefits, even though it can be a difficult process.

Right, now that that’s out of the way, on to the real news! The WebKit team have just released an upgrade to the interpreter used in their JavaScript core. While not particularly exciting news to begin with, the new interpreter — dubbed SquirrelFish⁵ — runs at a blistering rate compared to the old one. Now Safari/WebKit has never been a slouch in terms of JavaScript speed, as Apple are usually the first to proclaim, but this speed increase is truly astonishing. Check out the Apple speed comparison chart vs. other browsers, then the WebKit speed comparison chart vs. earlier WebKit versions.⁶ This is what WebKit have to say:

SquirrelFish is fast—much faster than WebKit’s previous interpreter. Check out the numbers. On the SunSpider JavaScript benchmark, SquirrelFish is 1.6 times faster than WebKit’s previous interpreter.

This kind of performance increase is not to be sniffed at in any way. For the technically minded, the SquirrelFish announcement does go into how the old syntax tree traversal has been replaced by "a register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention. It lazily generates bytecodes from a syntax tree, using a simple one-pass compiler with built-in copy propagation." Having had some prior experience writing a number of generalised interpreters for my final year undergraduate project I can tell you that given a decent compiler-compiler it’s relatively simple to build a (naïve) tree-based scanner then left-depth traverse it spouting code on a node exit/stack pop, but to perform the sort of one-pass technique they’re now using is truly cutting edge work.

One thing that I am worried about is how long it will take for this to trickle down into the release version of Safari. While I am willing and able to download and run the experimental engines from WebKit directly it’s obvious that many folks neither care nor know about the lag between the nightlies and the official releases. With an update to Safari included in the recent Mac OS X 10.5.3 release I imagine it will be a while before we see another update to Safari, and even then I imagine it will take a while before the new engine is tested well enough to be included in the official release.

1. Safari on the Windows platform has yet to impress me, but that’s fine as I don’t browse the web on Windows [↩]
2. I’ve only known two of the nightly builds to cause me problems and both were fixed in the next day’s updates [↩]
3. Although often the best you can do is use a newer version of the same engine, rather than swap it out for an entirely different one [↩]
4. Performance is usually the primary concern here rather than ease of change [↩]
5. I have no idea why [↩]
6. Confusingly, for the Apple charts shorter is better, and for the WebKit charts longer is better. Meh! [↩]