Slashdot Mirror
Firefox Gets Massive JavaScript Performance Boost
monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference."
An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.
Why is parent a flame bait? /. just yesterday had an article about a javascript attack in firefox that takes over the clipboard. I tried it on my firefox, and it worked.
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
There seems to be a bit of confusion on this issue. Runtime compilers (like what java uses) can and do produce faster code than native compiled C/C++, but it depends on how you define fast.
With JIT, what typically happens is that everything is interpretted at first, and the runtime compiler begins to analyze which code segments should be optimized. Because the compiler knows not just the source material, but how it's actually running it can do a better job optimizing the code than native C compilers could.
But there's one very big catch. For small tasks like 'ls' the native program loads instantly whereas the JIT compiled code does not. Also, if your program is rather heterogenius with few bits of code being executed repeatedly it will not perform as well as a native program.
Where this technique really shines is in cpu intensive programs. In the future, when you hear two people argue whether or not Java is slow compared to C++ it's good to remember they are both wrong.
Except that C so weakly typed that it's essentially dynamically typed. The only difference is that a C type error looks like this
Program received signal SIGSEGV, Segmentation fault.
Bob