JavaScript - a Flash competitor?

Open source software has its problems when it's trying to keep up with proprietary software, but when it does what it's good at – creating ideas and developing them very quickly in public – it can be revolutionary. Take TraceMonkey, a newly announced Mozilla-based project that speeds up JavaScript execution dramatically and thus speeds up the Web.

Open source software has its problems when it's trying to keep up with proprietary software, but when it does what it's good at – creating ideas and developing them very quickly in public – it can be revolutionary. Take TraceMonkey, a newly announced Mozilla-based project that speeds up JavaScript execution dramatically and thus speeds up the Web. Just sixty days old from the start of development, it's doing things that any proprietary company would be proud to present as the end result of intensive, expensive research. And it's doing them in the open, so we can peek inside and find out what's going on.

In the beginning is the word – in this case, JavaScript. JavaScript glues a lot of the Web 2.0 world together, but it's no speed demon. It's designed as an interpreted language; the server sends Javascript to a client, and that client has to parse and translate each line into machine code before any useful work is done. That's cool – it means that JavaScript programs don't have to worry about the details of a client system as long as it conforms to the language specification.

But fast code needs to be compiled, where the translation work gets done ahead of time and the machine code is loaded and run whenever needed. If you can save the machine code because you know you'll need it again, this is very useful. And modern compilers don't just translate, they also analyse how the program's structured and work out the most efficient way to produce the machine code depending on what's actually happening. This optimisation is the most difficult part of compiler technology to get right, but the one with the most potential for speeding things up.

There are JavaScript compilers, but the basic idea doesn't fit very well with Web use – who wants to sit around after a page loads while an entire program is translated before anything happens? It's also not very useful to keep copies of the translated code, given the huge number of different pages a web user will visit and the relative rarity of revisits to unchanged pages.

So a third way is being explored – Just In Time compilers, or JITs. These are a cross between an interpreter and a compiler: they interpret each line of a program as it is executed for the first time, but keep a machine code representation. Then, if the program goes back to that line (most programs have loops and program branches that ensure multiple execution of portions of themselves), the compiler knows to refer to the translation it prepared earlier.

That combines the immediacy of interpretation and some of the potential speed-up of compilation, and you get code re-execution without having to maintain a huge database of pages. However, it's not much good for optimisation; if you translate everything when you encounter it for the first time, you've got little chance of understanding enough of what's going to happen next. And as there's a lot you don't know while you're compiling, you have to create and keep lots of code that can cope with different possibilities. That takes up a lot of time and memory.

Enter the TraceMonkey. This is the latest JIT for JavaScript, and it's showing some truly awesome increases in speed. As the name suggests, it traces the code it's running, effectively analysing the program on the fly. In particular, it spots loops and program branches, areas where parts of the program are repeatedly run – and then traces through them, working out which paths are going to be most taken. Then it compiles those, taking the opportunity to properly optimise each path it's working on – it's got enough context by then. Loops are miniature programs in their own right, complex enough to be worth working on, small enough to make the task manageable.

Various interesting things follow. Why bother compiling stuff that's infrequently run? You can concentrate on the optimisable bits, and leave the interpreter to cope with the rest. One key observation is that nearly all time spent in JavaScript programs is in loops – there's just not very much linear, run-once code in the sort of Web tasks JavaScript does. And proper, focussed optimisation generates fast, lean results that work well in limited conditions, such as mobile phones. TraceMonkey is part of FireFox 3.1, albeit turned off by default, and thus simultaneously available in x86 and ARM. That's interesting in its own right, given Intel's insistence that ARM Web technology lags x86 by a year or two.

You can read a lot more about TraceMonkey, and tracing compiler technology in general, by following some of the links from the initial announcement. But the stuff you need to know is that in benchmarks, TraceMonkey is delivering up to 30 times speed improvements over the norm – with most useful stuff running between two and eight times faster. It's not finished by any means (what do you expect from a three month old?), and when you're writing compilers the devil really is hunkering down in the sulphurous details. Expect bugs for a while yet.

Yet the implications are enormous. TraceMonkey fans are saying that these ideas can make JavaScript a potential rival to Flash, allowing complex Web-based applications and services to be delivered in a completely open framework. On the evidence so far, they could well be right.

(To play with the TraceMonkey, download FireFox 3.1, do about:config and toggle javascript.options.jit.content to 1.)

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All