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."
What an absolutely horrible speed test.
First off IE6 is not tested, while it is still the most used browser. Also Opera 9.5 is not ready, it has so many bugs it just isn't funny anymore. Many sites break that worked fine in Opera 9.2.
But let's get to the good stuff. Yes in pure JavaScript like this, IE might be faster than Firefox. But in real world situations it clearly isn't. There is no test done on layout manipulation (and such) using JavaScript. Internet Explorer is notoriously horrible at this, especially if you use it combination with PNG's with alphachannel or complex CSS. Not to mention if you have to use JavaScript hacks because of IE6's lack of CSS support for the simplest things.
Funny is also how almost all JavaScript library speed tests I've seen put Internet Explorer far behind the others.
In 'real world' JavaScript performance Opera and Safari would be the winners, where I'd choose Safari as absolute winner, as Opera gains a lot of redrawing speed by cutting corners it should not cut which often result in display corruption (ie, the type that goes away when you force a redraw by minimizing and then maximizing the window again, or moving another window over Opera and then away again). Quite a bit behind in speed after Safari and Opera would be Firefox, followed even further back by Internet Explorer.
As a developer I still prefer Firefox for development though. Webkit is awesome, but the Safari GUI just plain sucks. Opera... hmm, I like it on my mobile devices, but it's just too weird for the desktop (what, textarea's don't even support scrolltop? wth!)
here
AMD Athlon 64 3200+, 1GB, Ubuntu 7.04, using FF for 4 hours, listening to last.fm.
CC.
TaijiQuan (Huang, 5 loosenings)
Compare it to the days of IE5.5 vs Netscape 6 (the worst browser ever released) vs Netscape 4.7 and you can see what huge progress has been made.
Nowadays it's perfectly possible to develop a complex script on FF (appealing because of Firebug) and expect it to work with minimal if any modification on IE and Opera.
I can second this statement. With libraries like prototype, and others that build on top of it, cross-browser development is simplified. The libraries take care of many of the differences between browsers, leaving the developer to work on the actual features.
Developers: We can use your help.
IE's string concatenation is ridiculously slow. I've found that in all browsers (except Firefox) it's faster to use an Array, push() together the string elements, and finally join('') them together to create the final string.
In Firefox, this is ever-so-slightly slower. In Internet Explorer, it's a good order of magnitude faster. (Depending on the length of the string. Concatenating a string 100 chars long together 10,000 times, I got a time of 13.7 seconds for plain old string concatenation ("string" + "string") versus .04 seconds for Array.push(). Firefox did the same test in .7 seconds using both methods.)
The SunSpider tests appear to be using plain-old string concatenation. I'll have to try rewriting them using Array.push() and see what the result is. Doing that IE's performance would almost certainly beat Firefox.
You are in a maze of twisty little relative jumps, all alike.
Okay, maybe not, but this is my numbers:
WinXP Firefox 2.0.0.11: 18.8s
WinXP Internet Explorer 7.0.5730.11: 33.1s (same issue with the strings performance)
Ubuntu Firefox 2.0.0.6 (yeah, well): 15.3s
I only have opera running on my WinMobile Dell Axim v51x PDA and it's currently running, it seems to be 30-40 times slower than the desktop, so I'll not be waiting before I post...
TC - My Photos..
I've done some work before that required concatenating very large strings in Javascript, and the code was certain to be run in IE by our users. It was clear to me from the observed performance, that when you use the "+" or "+=" operators to build a large string from many smaller strings, IE does not attempt to optimize things under the hood with a String Buffer. In fact, *every* "+/+=" operation seems to allocate an entirely new String object to contain the result. Problem is, most of those Strings are intermediate results that will just end up get tossed by the garbage collector, and hence their allocation was for naught. A quick analysis of this means that we're looking at a total memory allocation cost on the order of N*N, which leads to very unreasonable performance when you're looking at concatenating 1000+ strings. From scanning the SunSpider string benchmarks, it looks like the specific benchmarks that IE has trouble with are indeed using the +/+= ops to build big Strings.
Fortunately, there are workarounds. The easiest is put all the component strings you wish to add together into an array and then call join('') on the array to build the result string. This executes much, much faster in IE and should be fast in the other browsers as well. Before I figured out the join('') "trick", I implemented a scheme to add the component strings in a much more optimal order...the N^2 cost is only if you add them in a naive, left-to-right manner. By pairing up adjacent components and adding, you get N/2 intermediate results. Repeating the pairing process on these intermediates, and over again until you have your 1 final result, the allocation cost is only N*Log(N), which is far FAR better than N*N. Incidentally, this is similar to the "Russian Peasant Algorithm" technique used to optimize the addition of N numbers on massively parallel processors...whereby you can reduce the cost of N additions from N to Log(N) time assuming there are enough processors (N/2) on hand. When I learned about the join(), I compared its performance to the Russian Peasant technique and got very comparable results in IE. Weired, since if join() were using a StringBuffer under the hood (like it should), then its performance should be O(N), not N*Log(N)...
Anyways, in summary - yeah it sucks hard that IE does that, but it's easy to workaround once you know what's up (gee, that's true in so many cases with IE quirks).
The actual problem is the way JScript does string concatenation.
:)
When you concatenate 2 strings in JScript, it determines the size of the buffer needed, allocates the buffer, does the concatenation, and returns the result to the caller.
Which works fine, until you start putting some load on those old tires...
x = 'some';
y = 'string';
z = 'here';
testString = x + " " + y + " " + z;
(Ignore that nobody would actually write code JUST LIKE THAT, they would just add a trailing or leading space to the x, y & z strings. But concatenating a result with some white space is not abnormal.)
Now, just think about what this is actually doing under the hood..
1. determine len of x (4) plus len of " " (1) = 5
2. Allocate new buffer(5)
3. Concatenate, assign result to temp
4. determine len of temp (5) plus len of y (6) = 11
5. Allocate new buffer(11)
6. Concatenate, assign results to new temp, destroy old temp
7. determine len of temp (11) plus len of " " (1) = 12
6. Allocate new buffer(12)
8. Concatenate, assign results to new temp, destroy old temp
9. determine len of temp (12) plus len of z (4) = 16
10. Allocate new buffer (16)
11. Concatenate, assign results to testString
So, to concatenate relatively little string data, 3 temporary buffers were needed and 4 separate allocations were done.
It works fine, right up to the point where it doesn't
There is an error in the aggregating mechanism of the benchmark. Otherwise, it would work in the current Opera as well.
.. paranoid crackpot leftover from the days of Amiga.
I did the test on a dual-boot Intel Core 2 Duo 2.0 GHz with 2 GB RAM Comparing Vista and IE 7 with Ubuntu 7.10 and FireFox 2. Vista took 17461.6ms and Ubuntu took 12532.4ms for a 15% improvement.
Here are the links to the full reports:
Windows Results and Ubuntu Results