Next-Gen JavaScript Interpreter Speeds Up WebKit

JavaScript is everywhere these days. Now WebKit, the framework behind (among others) Safari and Safari Mobile, as well as the yet-unreleased Android, is getting a new JavaScript engine called Squirrelfish, which the developers claim provides massive speedups over the previous one. The current iteration of the engine is "just the beginning," they claim; in the near future, six planned optimizations should bring even greater speed. With JavaScript surviving as a Web-page mainstay despite many early gripes, and now integral to some low-powered mobile devices, this may mean many fewer wasted seconds in the world.

Re:The real question is....

[samkass]

According to this link [satine.org], the SquirrelFish in the latest nightly build (without the extra optimizations) can already compile *and* run the source code between 1.08x and 1.94x as fast as Tamarin when Tamarin is just running pre-compiled code. It's fast.

Re:squirrelfish?

[BenoitRen]

SeaMonkey [seamonkey-project.org], of course. :)

I made a Mozilla product name generator [skynet.be] a half year back.

Javascript grows up

[Slur]

"With JavaScript surviving as a Web-page mainstay despite many early gripes..."

This notion has long been outmoded... well, at least for the past few years.

Javascript is doing more than just surviving. Early implementations of Javascript were quite buggy and standards were pretty lax. Things have improved significantly since "Javascript" became ECMAScript. The name may still have "script" in it, but it's a huge misnomer. Javascript is a full-fledged language - a very powerful one with many unique properties, and very useful if you know how to apply design patterns.

I encourage anyone involved in building websites, widgets, or enterprise applications to check out the Javascript lecture series by Douglas Crockford of Yahoo! located at http://video.yahoo.com/video/play?vid=111585 [yahoo.com] to get a real feel for the power of modern Javascript.

And have a look at the modern AJAX frameworks like YUI and JQuery, which are being used to develop some pretty complex applications.

Re:squirrelfish?

[Cochonou]

Your post made me laugh - a lot.

But incidentally, the squirrelfish is an actual fish (just like it turned out that the firefox was also an existing animal).

Re:Nothing can beat Opera's dev team

[diegocgteleline.es]

If opera dev's team can't be beaten then they must have a ultrafast version hidden somewhere, because the public versions, including 9.5 betas, are already slower [zdnet.com.au] than firefox 3 and webkit on many benchmarks

Re:iPhone Safari

[compro01]

It's an engine that complies (or at least tries to) with standards.

Re:jython (take two)

[Daniel Dvorkin]

Jython is Java + Python, not Javascript + Python. Two completely different beasties.

That being said, if the Squirrelfish VM and interpreter strategy are applicable to other languages besides JavaScript, some sort of "JSPython" strategy for putting lightweight (i.e., not requiring the JVM as Jython does) client-side Python scripts on web pages would be pretty cool. There doesn't seem to be any suggestion of that so far; presumably (and quite sensibly) the Squirrelfish folks are concentrating on getting everything right WRT JavaScript before they try expanding its scope like that.

Re:Real question:

[Anonymous Coward]

the source is already available: http://trac.webkit.org/browser/trunk/JavaScriptCore

why would the WebKit team be interested in merging code from a slower implementation?

Re:Konqueror/KDE 4.?

[Anonymous Coward]

Oh yes I can tell you: konqueror is coming with khtml by default. There's a webkitkpart ()which is not quite ready) and there's a GSoC student working on it though so it might work better at end of this summer. IF you want an open source browser in linux using Webkit, you can use Arora: http://code.google.com/p/arora/ or the epiphany branch that uses webkit.

Re:Still Stateless

[ergo98]

Every time you click a button that triggers a server-side transaction, the page needs to explicitly transmit info - a cookie, GET/POST variables, something - back to the server to "remind" it of its current state.

How do you think TCP works atop the "stateless" IP?

The whole stateless/stateful thing is extremely dated, and not even logically correct. HTTP w/cookies is stateful, and has been for a long time [yafla.com].

How about low-end PCs?

[BUL2294]

Just for the hell of it, I've got Firefox 3 RC1 running on an ancient Toshiba Libretto 110CT with 64MB RAM running W2K on a Pentium-MMX 233. Looking at JS benchmarks online, with Firefox 3 (presently) leading the way, I figured it was worth a try... FF3 is way more usable than Firefox 2.0.0.14... In fact, the full version of GMail actually runs on the Libretto! (Firefox 2 would go into JS hell with the CPU pegged at 100% for 10-20 seconds at a time...)

One can only hope that we could squeeze some more JS performance...

Re:The real question is....

[Jugalator]

I agree, Safari for Windows is actually a bit tempting, especially if "hacking" it a bit (actually, it can probably not even be called "hacking" in geek circles at least) to use the latest WebKit builds. The only downside of that one is its (sorry..) piss poor memory performance. It's worse than pretty much anything I've tried. A few hours browsing and I had it use 300-400 MB RAM. That's like the bad old Firefox 2 days at worst, from my experiences. It's worse than IE 7 too.

Re:The real question is....

[ToLu the Happy Furby]

Faster than the current Mozilla builds of Tamarin, which have not been optimized and in many situations are still slower than SpiderMonkey.

On the other hand, it bears noting that Tamarin isn't going to make it into shipping code until Mozilla 2.0--presumably that will be Firefox 4, but it's still so far off that I believe that determination hasn't even been made yet. Whereas on past experience I would expect SquirrelFish to be in a shipping Safari build much sooner.

Re:plug-and-play javascript engine

[Goaway]

There is no such thing as a "CSS interpreter" separate from the browser. The rendering engine and the CSS handling code are almost entirely one and the same.

Re:Still Stateless

[moderatorrater]

He's not commenting on stateless applications, but the stateless quality of http. Every time the browser communicates with the server, it has the exact same overhead, whether it's an ajax request or a full web page. The amount that's sent back may differ, but it's still sending all the information associated with instantiating a new connection, sending information about the browser, all the cookies, etc. When you build stateful applications on top of http, you incur a lot of overhead in those headers and cookies being sent back and forth. For applications trying to stay synced to the server, some people have found overhead of over 75%. This inefficiency's being made up for in packing more information into each request, stretching requests out to take up more time, and just plain fast processors and connections.

The GP is saying that if we had a stateful protocol, we could eliminate most of the overhead and make applications move a lot faster.

Re:Javascript grows up

[djbckr]

I appreciate the sophistication of JavaScript, but I hate writing in it. Call me old fashioned I suppose, but I simply don't like the holes you can dig in JS. I recently became aware of the Google Web Toolkit. It really bridges the structured programming I like with the Web 2.0 feel I like my sites to have.

Re:The real question is....

[TheRaven64]

To give some context to your remark:

The fastest dynamic language implementation at the moment is Objective-C. This isn't as fast as it could be in the GCC implementation (I'm working on it in LLVM, and hope to have some nice speedups soon), but it's not far off. This compiles dynamic lookups to fast native code and compiles everything else to static code.

Next up in terms of speed are the various Smalltalks. Something like GNU Smalltalk does well in terms of speed. It JIT compiles things in a way quite similar to Objective-C, but with a very naive compiler with very little optimisation. This is slightly faster than something like Squeak, which compiles to bytecode and interprets this. Bytecode is generally quite fast. Basically, the interpreter is a loop which contains a switch statement. Each instruction is a fixed size with (typically) the first byte being an opcode, and so this is compiled to a static jump table and the 'decode' cost for each instruction is a load and a jump. This is slightly slower than naive compilation, but not much. In some cases it can be faster, because your interpreter is likely to be compiled with a compiler that does quite aggressive optimisation and so you may get fewer register spills than something like GNU Smalltalk (which lacks a peephole optimiser, for example). The new JavaScript interpreter is of this nature - it compiles to bytecode and then interprets this.

Even slower are interpreters which try to run the AST directly. These turn each statement (or part of a statement) into a generic operation and step through these. This is what the old WebKit implementation did.

Part of the problem with this kind of thing is that you are always trading compile time for run time. The benchmarks they published take around 10 seconds to do a complete run. This includes both your compile and run time. If you take more than a second to compile, people will notice. If you take one second to parse, and then execute the AST slowly, you may take 10 seconds in total. If you take one second to parse and four seconds to compile and optimise then you need to get a 500% speedup just to break even - your perceived speed will be the same. This is why things the StrongTalk and Self VMs did dynamic profiling - they began by interpreting everything, but if you spent a lot of time executing a part of the code, it will aggressively optimise it. The newer Java VMs do the same thing.

For most JavaScript, this is a complete waste of time. It is very rare for JavaScript to run for more than a fraction of a second at a time and so latency caused by interrupting execution much worse than just running it slightly more slowly. The ActionScript VM in Flash is very different, since it is designed to run scripts that stay running for minutes at a time and are fairly CPU intensive. If people start using JavaScript and canvas tags or SVG in the same way as they use Flash, then a JS runtime with a JIT compiler and optimiser is likely to be a win.

Re:iPhone Safari

[buckhead_buddy]

On a mac, it's simple to install and remove the WebKit nightly. It's literally just dragging and dropping a specially built application.

1. Make sure you have the latest Safari installed. WebKit doesn't touch the User Interface, so you still need Safari around.
2. Go to the Webkit Nightly Builds [webkit.org] site and click to download the Mac OS X version.
3. If you have "Open safe downloads" wisely turned off, you will need to find the file you downloaded (probably named WebKit-SVN-r#####.dmg) and open it. The disk image will mount and you will see a gold version of the Safari compass icon labelled WebKit. If your browser auto-opens "safe" downloads, just switch to the Finder and you'll see that gold WebKit icon all alone in a window.
4. Drag the gold WebKit icon into your Applications folder. It will not conflict or erase Safari since it has a different name. You are now done with the install image; you can eject and trash the .dmg file from your download folder.
5. To use the nightly builds of webkit, launch the gold WebKit app rather than Safari. The first time you will be warned by Mac OS X's security feature saying this was an app downloaded from the internet, go ahead and approve the launch. You may also be warned about the incompatibility of some browser plugins. Everything else should seem identical to Safari.

Now, you'll only be using the webkit libraries when browsing with that gold WebKit icon. To prove this to yourself, you can visit the Acid3 test [acidtests.org] page using both Safari and Webkit without quitting either and see very different results. Safari still has major incompatibilities while WebKit seems almost perfect.

Finally, when you are ready to uninstall WebKit, quit the app and drag the gold colored icon from the applications folder to the trash. Or, drag a new version that you download the next day on top to replace the old nightly.