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.
Gecko *is* a full-featured framework.
ExtJS is for the more restricted web stuff without code signing.
But then, the parent probably doesn't even know what a prototype is or a closure.
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.
Wow, that's phunny as phuck, you phucking gee knee us.
A language designed by incompetent fools like you is just going to be Java. You guys just can't accept anything you've not been programming in.
Tied too much to the browser... Have you ever tried Rhino? You can do file I/O, socket I/O, write OpenGL graphics, and do anything non-browser with it. You can also embed Spidermonkey in your own non-browser apps if you like. It's not JavaScript's fault that you haven't even tried.
No reflection... If you don't fucking know what reflection means, look at Wikipedia.
No dictionary... Someone else's library is messing up your data structure it's JavaScript fault? If I've written a library that makes STL's map stop working, and you somehow included my library, is it STL's fault?
Nothing resembling libraries... What's Dojo, extjs, jQuery, prototype, etc.? Or do you want only one common library tied to the language? IF you say it's not coming with the kitchen sink like Python did I'll let you pass... But is that really needed?
No threading... Take a look at Google Gears worker pool or Rhino's.
No classes... Prototype-based and class-based programming are just two styles of implementing OOP. How about you give us a concrete example about some important common code that you can mathematically prove to be not implementable in protptype-based language? Instead of complaining that an orange does not taste like an apple?
Scoping... Write an anonymous function and you have a scope. If you're so used to {} giving you a new scope in C... Man, this is not C.
I'll let you pass on namespaces. No namespaces is bad. But how many % of your time is wasted because of "no namespaces"? How about you justify it in concrete terms instead of "Oh, this language does not let me do logic programming like Prolog does!". Do you really need every feature of every language on Earth in one language just to survive?
All those "The language haven't implemented X for me" complaints... How fucking hard is it to write the mousedown, mousemove, and mouseup handlers, and calculate the delta positions, and wrap them up as a neat reusable object yourself?!?! If you think that is hard I seriously suggest you hand in your geek card - you're not a programmer at all! And there are plenty of libraries out there that has implemented and debugged that 10s or 100s of lines of code for you. "Oh yeah I can't write 90 lines of very simple logic correctly and I'm a programmer! JavaScript is so fucking hard!"
Browser bugs and inconsistencies... Pain in the ass but that is not the language's fault! If the browsers let you use C or Python or LISP to manipulate their DOM you'll have the same bugs!
I think I've had enough bullshit from people like you. People like you don't do the simplest kind of research on any matter, people like you confuse concepts. Oh, XMLHttpRequest is hard to use? "That must be JavaScript's fault again! I can't even fathom the possibility that I might be barking up the wrong tree!" Yeah, give JavaScript namespaces, make JavaScript class-based, or even just scrap it and make it Java! And still the thing that wastes you the most amount of time - browser bugs and inconsistencies (e.g. status code from socket errors from XMLHttpRequest in IE vs. Firefox) won't go away! Oh, the fucking economy tanks again! That must be JavaScript's fault!!
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