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."
Looks like they are finally getting their javascript act together. After being a sore point for so many years, a working javascript in Opera will be welcome.
Because of the incompatibilities and different bugs between browser JavaScript implementations for God's sake let's not have a world where client-side JavaScript is so fast we use it for everything. Development time will increase one more fold for each browser you want to support, and sometimes additionally for each minor version It will be hell on earth I predict.
My basic rule of thumb has also been that client scripting should enhance and application but not be required for the application. In other words with JavaScript disabled the application might act rudimentary but will still produce results.
Yeah, what's far more important to me than "how fast does this browser run Javascript?" is "how easily does the browser non run Javascript?"
Why don't people just stop making ridiculously complicated pages? Have you seen the yahoo hompage? Aol's is even worse. And Ebay's is a ridiculous nightmare. I don't who thought that looked good or thought people will look at or read that much but they should be fired. No browsers in the world could render those pages in under a second the way they're supposed to look. Plus remember that like 99% of page load slowness is from ad servers failing to load the ads fast enough
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
He says: "What surprised me here is that Firefox is substantially slower than IE, once you factor out that wildly anomalous string result."
;-)
To paraphrase: "What surprised me here is that Firefox is substantially slower than IE, once you manipulate the experimental data by removing something that IE is particularly slow at."
And guess what? If you remove string ops, bit ops, and date ops, then Firefox is probably faster than IE.
There could be a good reason for the test showing poor performance - say IE is shit at string concatenation - and then the result reflects badly on IE. Or, it could be that for whatever reason the benchmark hits some strange edge case that virtually never crops up in normal usage, in which case the benchmark should be thrown out. But without further information you have to just treat the result as null. It's an unknown.
do {print "Mini-Geek Rules!\n";}
until ($TheEndOfTheWorld);
IE wouldn't be faster than that much faster than Firefox 2, and no faster than Firefox if we 'filtered out' this anomalous reading. Assuming the string operations took 1.5 seconds (a nice round number in between Firefox's and Opera's times), we could subtract 12.9 seconds from IE's overall time of 21.2 seconds and arrivate at 8.4 seconds, putting it neck-and-neck with FF3 and still less than 25% faster than FF2's performance. FF2 is slow, but he makes it sound like FF2 sucks badly and it's just not that bad.
That being said, one can't be sure that IE7's string reading was 'anomalous' without significantly more data.
Also, I wouldn't make that much of the difference between Vista 32 and Vista 64 or between a 3.0 Ghz and a 3.2 ghz Core 2 Duo. Browser performance is likely extremely similar on both systems for all browsers, with the possible exception of IE7's (I have a sneaking feeling the 'anomalous' reading is an issue particular to 32-bit Vista)
My blog
You know, it's cute to refer to "the big four" browsers, but you could've at least listed what you think those are - we are not mind readers.
Had it been "the big one and the one that just edged into relevance", then most people would know what you meant.
sic transit gloria mundi
AFAIK, Tamarin was since the beginning scheduled for Gecko 2 (i.e., Firefox 4). So, don't worry, it's not like it didn't make for Fx3, it wasn't supposed to be on this week's beta at all.
Posted in the comments to TFA:
There was an article about IE's string performance in the Jscript team blog on MSDN a while back : http://blogs.msdn.com/jscript/archive/2007/10/17/performance-issues-with-string-concatenation-in-jscript.aspx
Aaargh! on December 20, 2007 11:34 AM
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Try a heads up between Firefox and IE after the average-joe user has had a few weeks to accumulate spyware.
I'd like to see those results.
I think this "benchmark" is deeply weird. It only exercises the pure execution paths, while pretty much ignoring all of the data structures that make a web page work. Every web app I've written or tried to optimize is limited not by time spent in javascript, but rather time spent manipulating the dom and drawing.
I guess there's value in such a benchmark, but it goes against the conventional wisdom of Amdahl's Law. If JS execution accounts for only 10% of the runtime of your application, it will be of little value to make JS 20% faster. You must concentrate on the other 90%.
Once you need a benchmark to prove something is faster than something else, then it doesn't really matter which one you uses.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
I just profiled your page with Venkman and it seems that > 96% of the CPU time is spent in document.getElementsByName. Were you trying to prove my point?