Massive Javascript performance improvements on the horizon

[jducoeur]

Web programmers should take a look at this article in Ars Technica, which talks about a radical enhancement that will be coming to Mozilla soon.

Summary: they're about to integrate trace optimization into the Spidermonkey Javascript engine. The underlying concept of this technique (assuming that I'm understanding it correctly) is essentially that it learns as it goes, making the program faster as it figures out how it really works in practice. This notion isn't quite as new as they make it sound, but this would be the widest deployment of it that I've heard about so far. In principle, it could eventually allow some Javascript programs to run *faster* than compiled code, because trace optimization can accomplish some speedups that compilers can't.

From the numbers they show, it looks like the new Javascript engine performs something like twice as fast in ordinary conditions, and up to 20-40 times faster in some cases. (Probably involving key loops that can be optimized well.) While that doesn't totally change the world yet, it's another key step in turning Javascript from an annoying and clunky toy into a language capable of serious work. And it means that, at least in Firefox, some complex web apps are about to get a speedup without having to do a thing. (It also means that the browser itself is likely to speed up in many places, because much of it is written in Javascript...)

Comments

[zachkessin.livejournal.com]

Wow that will be really nice.

[metahacker.livejournal.com]

In principle, it could eventually allow some Javascript programs to run *faster* than compiled code, because trace optimization can accomplish some speedups that compilers can't.

So why not include trace optimization into some sort of re-compiler? I could guess that's the idea behind JIT compilers, which seem like they're out of vogue currently. I'm afraid I'm out of touch with this stuff and don't really understand why the above might be infeasible.

[laurion]

Might it have to do with user interaction? If you have two loops equally likely, and the user selects one, you optimize that one. Optimizing both may be mutually incompatible? Or maybe JIT memory management.

[jducoeur]

Well, as far as I can tell from the descriptions, this technique is at least similar to some of the JIT technologies (which is why I said it wasn't quite as new and revolutionary as they make it sound -- it's just novel to incorporate it into an "interpreted" language).

Not sure why you think of JIT as being out of vogue, though -- far as I know, it's faded into the woodwork simply because it's universal at this point. Are there are major IL-based environments that *don't* have JIT baked into them? My understanding was that at least Java/JVM and C#/.NET (the overwhelming favorites in the IL space) do so pretty deeply...

[metahacker.livejournal.com]

That may be it -- JIT isn't the new thing, it's what everyone does, so you don't hear about it any more.

Trace optimization in compilers

[metageek.livejournal.com]

I know I've read about recompilers that use execution profiles to advise the optimizer...yeah, here's a paper on it, apparently from 1993.

JITs don't necessarily do trace optimization; some do, apparently, but the basic JIT generates machine code at runtime, but does so without any knowledge of how the code is used. The only real reason for doing it at runtime is if you want to be able to distribute a machine-independent program (e.g., Java bytecode).

[crschmidt.livejournal.com]

For the record, increase in speed in SunSpider test running (the canonical JavaScript interpreter speed test) is almost entirely unrelated to speed of how web applications perform, in my experience.

The speed of the DOM interactions -- at least for OpenLayers -- are so much more important as to be dwarfing everything else at this point. For example, FF3 runs about 10% faster than Safari 3.1 on my machine, but the OpenLayers test suite runs about 5x faster in Safari.

It's nice that they're putting all this effort into improving Javascript performance, but really, all they're doing is taking a part of web application interactions that is pretty small potatoes -- the Javascript algorithms/function calls themselves -- and making them an even smaller percentage of the total time. Going from JS calls taking 10% of the time to 2% or even 1% of the time still only gives you an 8%-9% speedup overall -- enough to show up in performance testing, but not really enough to show up on users radar as being much faster -- and I'd be surprised if 'tracemonkey' is really going to offer even that much of a speedup in application code that isn't doing a lot of looping.

(I did try to build tracemonkey to test with, but failed to do so yesterday. Did get JavaScriptCore, and the JSC standalone compiler, working though. And found out that Rhino is 10x slower than year-old spidermonkey on some simple tests I did, which is pretty impressive.)