Slashdot Mirror
Comparing Browser JavaScript Performance
Thwomp writes "Over at Coding Horror Jeff Atwood has an interesting writeup on JavaScript performance in the big four browsers. He used WebKit's newly announced SunSpider to produce the results. If a probable anomaly in the IE7 results is overlooked, Firefox 2 is the slowest of the bunch. Atwood has also benchmarked the latest Firefox Beta, and its performance seems to be improved significantly."
Take note of the tests for the latest Firefox beta though, notice that he's using a different system with .2Ghz more and he's on a 64 bit system versus a 32 bit. Although it's not a huge leap, it IS a difference. Different system different benchmark.
The "probable anomaly" is that it is an order of magnitude slower than every other browser at string operations, which are a kind of important feature of Javascript. I'm not sure why he sees this as a probable anomaly, but not any other result where one browser does a lot worse than the others (no browser appears a clear winner or loser on everything, though Opera does come out in front more often than the others).
Aside from jscript lacklustre string handling, I've still never found it faster than spidermonkey. In some base64 tests I did, Opera fared really badly using an algorithm I found on their site -- while leading the pack with one I wrote myself. What I discovered was that given the right set of tests, any implementation can look favorable.
The unoptimized spidermonkey cli shell firmly trounced kjs last year when I did my testing, more likely what's being measured by these benchmarks is DOM access.
Bizarrely, Firefox for Windows running through wine runs faster than native Firefox. The wine installation doesn't have any add-ons though, so that might be the difference. Wine version is 0.9.51 and windows firefox version is 2.0.0.9, same machine as my post above.
Wine results. Native results.
FireFox was supposed to be getting a JIT compiler for JavaScript. It's the one from the Flash player, where it runs ActionScript. That's apparently now expected in 2008. Then we'll see some real improvement.
Firefox, for me, is really stable unless Flash is involved. Add Flash to the mix, and it goes down faster than a two dollar whore on a Friday night. By the way, so does Opera, but not quite as often. Close though. Just try watching 4-5 videos on YouTube.
I think Flash is the biggest DoS in the history of the web and Adobe really needs to take a good look at it. With all of these Flash ads and Flash-based video players, it really is a critical issue. Using adblock is an absolute must in my book, just to keep the browser running. My bet is some sort of resource leakage, since it happens over time -- like when watching several YouTube videos. It doesn't crash on the first or second one, but you're courting disaster on the third and above.
By the way, is there any way for FF to handle plugin crashes gracefully, i.e. *without* bringing down the browser with it? Maybe running it in a separate process somehow and just putting up a "broken image" sort of placeholder?
If you run the MooTools Slickspeed tests in different browsers, you find something interesting:
jQuery also claims to be the most accurate, though who knows for sure.
$nice = $webHosting + $domainNames + $sslCerts
This is speculation, but I think that the browser may use the COM MicroSort VBScript Regular Expressions 5.5 library, at c:\WINDOWS\System32\vbscript.dll, for doing regular expressions.
If that's true, (and I figure someone will calibrate me if I'm wrong) that could explain an apparent performance anomaly, if the browser farms out the string manipulations to another process.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I can attest to IE's crap string operation performance.
... d'oh!). Cutting out that single substring operation dropped it back to 1 minute. Changing over to DOM manipulation left it at 1 minute.
4.5 HTML file, mainly consisting of one very large table. Took about 1 minute to render in IE, using about 80MB RAM. Was asked to lay it out in a more useful way. I went the fairly simple route - once it was fully loaded, I used JavaScript to lay it out better.
Original attempt was to just use innerHTML and string operations (couldn't remember the DOM commands, too lazy to look them up). The main bit was a single substring() on the div containing the large table (actually stripped off everything around the table).
The time to render the page jumped to 10 minutes! Memory use jumped sharply as well (largely because I was duplicating the table
For comparison, Safari 3 on Windows rendered the entire page in 5 seconds, whether I used innerHTML and substring() (including the duplication mentioned above) or DOM manipulation. Safari used a bit more memory than IE though (worst case 215MB compared to 200MB).