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

[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).