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.
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.
Script kiddies will be able to infect a Windows user in record time! Seriously,I install Noscript automatically with every new build and show the customer how to use it. It has just gotten too easy to infect Windows with JavaScript and it seems like everyday you're reading of a new JavaScript exploit. So it is safer just to kill it than to take the chance. So for me and my users at least it doesn't matter how fast FF renders JScript,because it has just gotten too dangerous to use. It is like saying "We've increased the speed of ActiveX by 300%!". But as always this is my 02c,YMMV
ACs don't waste your time replying, your posts are never seen by me.
Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?
All your base are belong to Wii.
Now if we can just stop all the xss. Now it's just xss 20-40 times faster (in certain contexts).
Actually, if JS gets fast enough, it could rival Flash. This is a good thing.
THL phish sticks
Will it make my Sony Bluray player take less than 10 minutes to boot and play a disc?
Firefox 3 already gave quite a nice performance boost to Javascript, enough to actually impress me (google maps is a great demonstration of this). It's good to see they haven't stopped there and are busy improving it further, a lot of software developers tend to spend too much time on making new features and not enough time fixing/optimising the existing one, but I think after the backlash from FF2's memory usage, Mozilla has rethought their priorities and I'm glad to say they're doing things right.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
What does the scouter say about its power level?!
The theories behind tracing optimization were pioneered by Dr. Michael Franz and Dr. Andreas Gal, research scientists at the University of California, Irvine.
Hey that's my old compilers professor and my school!
This PDF looks like the paper the article is referencing.
I've written my share of JS-heavy apps and the boost will be nice for that. However, my complaints with JS don't lie with performance.
I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.
Basically my point is that performance does not bring JS up another tier. It just prolongs the pain of having a grossly inadequate language for rich application development. JS does have some nice things about it (first-class functions, closures, for(..in..), etc.) but in no way would I consider it "good" for application development.
Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer and this performance boost is just a Bluepill in disguise.
:wq
In general, JIT systems can really provide CPU performance near C speed, or even faster for some benchmarks, once the application gets going. The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.
Even dynamic languages like Python can have a JIT - it specializes a function for various combinations of argument types, and then provides a catchall generic version for general objects. The catchall version is not much faster than the interpreter, usually (in fact it could *be* the interpreter), but the specialized versions can be much, much faster. (Also blocks can be specialized within any of the function versions.) But all those specialized versions take up memory. So the JIT keeps stats and tries to make only the ones that really help.
Expect this discussion to be full of astroturf, red herrings and trolls
Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)
It would nice to see some demos of this with John Resig's Processing.js. It could definitely use the kind performance boost being discussed here.
In addition to a performance considerations, it would also be nice to have addtional some additional bit depth in JavaScript.
I anticipate JavaScript will continue to be very popular, but there are alot a lot of reasons other than performance that people won't want to use the language for writing desktop applications over C/C++/Java. That said, there have been alot of recent developments that have made me cautiously optimistic about the future of the language along these lines.
I am rubber, you are glue.
It won't be just from the Windows side - a good chunk of Linux-heads hate anything but static black text on plain white backgrounds. So this should get interesting...
Goes to show what you know. Real Linux-heads hate anything but static white or green text on plain black backgrounds.
My wording was wrong - I did understand your paragraph and was merely trying to point that JS could be very helpful when doing SS'ing since it has native Dom parsers and methods. Indeed, there are many things in JS that lend itself well to being able to "read itself" - see Douglas Crockford's comments on JSLint, for instance.
Ever since the matrix, it's been green text on black background. That movie was 10 years ago, get with the times man!
However, I never said that improving JS performance is undesirable. It's the old scripting vs low level programming debate: Low level is faster, but needs more expertise and programmer time. Pick the best tool, etc.
The Mozilla architecture is a case in point. The UI is controlled by JS functions, which delegate all the hard work to XPCOM objects. That's more overhead than controlling the UI in C++ directly, but has the _huge_ advantage of being easier to modify and adapt the code for developers.
Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.
Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.
The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.
Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.
About the memory, you are correct (for now).
About the speed:
I made a benchmark written in a pure C subset of C/C++/C#/Java in all of these languages. A simple benchmark involving calculations with integers (primes) and floating point numbers (sums of products of square roots of primes). The result, when running a bazillion iterations:
C# and Java took 50 seconds, C++ took 49 seconds and C took 51 seconds. Other benchmarks I made showed similar results.
So for pure calculating, C#/Java + JIT is equally fast. For big real-life systems involving a lot of other stuff, the results might be different.
But it is a long time ago that Java et. al. were 3 times slower than native code.
Does the DS have Age of Empires? FEAR? The simple fact is if I tried that the shop down the street would get the business and I am out on the street. You can't force your customers to take what they don't want. Rule One of Business: The customer is always right. I had four Linux boxes in the shop and had to reformat them because they were just gathering dust. The home user wants to be able to take the software he/she buys at Wal Mart and go "clicky clicky,next next next" and have it work,PERIOD. if it doesn't the machine is "broken" and it gets returned. And NOBODY wants to be handed a DS when they ask about games. Do you HONESTLY think if I did that to my customers they wouldn't just walk out?
This kind of attitude is EXACTLY why Linux has been stuck in the hobbyist section for so long. Instead of an honest discussion about what customers wants and needs you get told "Buy a PS3" or "stick with Winblowz". Guys like me would love to be able to sell easy to maintain Linux units,but the simple fact is we don't want to starve. My customers DON'T WANT a PS3,they want to pick up a game at Wal Mart and have it work. They DON'T WANT a $200 HP added to the price of the unit,they want to take their Lexmark all-in-one that they are quite happy with and have it work. If I was to adopt that elitist attitude my shop would be out of business in less than three months,instead of being busier than ever. Because I ask what they are going to do with their new PC and design it around their needs. Here is what I have found would be needed for Linux to take off in the home/small business sectors based on my customers:
1. VB6 support out of the box. Every single SMB I've ever done business with have one or more VB apps that are essential to the companies survival. No VB,no sale. 2. Windows software and games should be installable from the CD,especially games. If they pick up something at Wal Mart it had better work when they put in the disk. No easy way to install games? No sale. 3. An NDISWrapper for printers,especially those damned Lexmark all-in-ones. They are popular for a reason. They are cheap and give the folks what they want,an easy to use all-in-one printer/scanner/fax. No Lexmark support? No sale.
Without these 3 things I just can't give a Linux machine away. Folks simply don't want them. I have been able to sell the EEE because folks look at them as a "toy" that they don't expect to do the things a "real" computer can. But with a desktop they have expectations: they expect the software they buy to run,they expect the programs that their business depends on to work,and they expect their hardware like printers to just connect and go. Without that,they just sit there gathering dust. But as always this is my 02c,YMMV
ACs don't waste your time replying, your posts are never seen by me.
And stay off the chans.
So basically you suggest doing the exact opposite of what has been shown experimentally to work very in the article?
Doing anything that can be done server-side on the client side is generally a bad idea
Oh, I don't know - what about the simple stuff like form validation? On a high traffic site, receiving a complex form from a client, only to have to send a page back saying "sorry, you forgot this field,do it again" seems to be a waste of both the servers resources and the user's time. Better to just have a JS popup telling them and changing focus to the problem field - no effort on your server's part is needed.
Of course, double-check everything you get at the server, just give the client a chance to sort it out at their end first before troubling you with it.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
On the off-topic note: Don't even bother thinking about the task manager, just download the Process Explorer and set it to replace the task manager. It's light weight and vastly superior to the task manager in every way. One of the utils I miss in Linux.
Switch back to Slashdot's D1 system.
tip: don't use Task Manager, for investigating performance issues, use PerfMon (under administrative tools on your start menu).
Open a performance report, add the %CPU counter for just IE (it'll be under the Process counter set).
You can get it to update faster than 1 second default, and get it to log to a file instead so you can view it later. Add a network counter and memory counter too for more insight.
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C.
The C# JIT has all the information that a C compiler has (essentially, the entire source code). In addition, it has a lot of global program information and it has runtime statistics. And, the C# language has better defined semantics. All of this taken together means that C# can be optimized better than C.
In terms of performance, C is a lousy language; Fortran is a "faster language" than C.
The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.