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."

Comments

A grain of salt

[pwnies]

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.

Re:A grain of salt

[Mini-Geek]

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.

Yes, it's a different system, so you shouldn't compare that FF3 number to the IE/Opera/Safari numbers, but you can still compare it to the FF2 number there (BTW that FF2 number is even a little slower than the one that all tests were run), which obviously shows that it's faster.

Re:A grain of salt

[philwx]

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.

Re:A grain of salt

[Jeffrey Baker]

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%.

Hmmm

[ubrgeek]

> if a probable anomaly in the IE7 results is overlooked

Like what? It didn't crash the system or it actually launched ;)

Re:Hmmm

[jrumney]

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).

Re:Hmmm

[chrb]

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. ;-)

Re:Hmmm

[gazbo]

Exactly because it's an order of magnitude slower. In all other tests it is a similar speed to all other browsers, then in one particular test it is ridiculously slower. There are no other tests or browsers that exhibit this behaviour, else I expect he'd have discounted them as anomolous also.

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.

Re:Hmmm

[_xeno_]

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.

Re:Hmmm

[mulveling]

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).

Re:Hmmm

[tdelaney]

I can attest to IE's crap string operation performance.

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 ... d'oh!). Cutting out that single substring operation dropped it back to 1 minute. Changing over to DOM manipulation left it at 1 minute.

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).

Ooh ooh let me guess

[The MAZZTer]

With NoScript, Firefox's performance easily soars above the rest?

Vista + ie7 took hours!

[mseidl]

<html>
<body>
<script type="text/javascript">
var i=0
for (i=0;i<=10;i++)
{
document.write.UAC("Cancel or Allow?");
document.prompt("Yes, No, Maybe?);
}
</script>
</table>
</body>
</html>

Bah humbug!

[SirJorgelOfBorgel]

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!)

Re:Bah humbug!

[Phroggy]

First off IE6 is not tested, while it is still the most used browser. The WebKit team released a test suite, they didn't release test results. If you want to test IE6, then test IE6!

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. This is intentional. This is specifically a JS speed test, not a DOM speed test. If IE's DOM handling is horribly slow, that's a different issue - not an unimportant one, but a different one. This test is really deigned for browser developers, not users, and that's important: while users don't usually care about specific implementation details and just want an overall faster experience, developers can only focus on specific implementation details. Thus, developers interested in improving JavaScript performance need to be able to look at JavaScript performance without being thrown off track by DOM problems, which are probably the responsibility of a completely different team of developers. JavaScript developers probably can't fix DOM problems, just as DOM developers can't fix JavaScript problems.

Re:client side javascript will become our enemy

[gazbo]

Incompatibilities are disappearing at an alarming rate. 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. Sure there are browser-specific functions, but they are almost invariably easy to avoid; the only real exceptions I can think of are different XML DOM methods, especially WRT namespaces.

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.

Re:client side javascript will become our enemy

[SirJorgelOfBorgel]

Oh really? JavaScript is not that hard to get to work correctly cross browser. I spent a LOT more time changing CSS things to work nicely than I do on JavaScript and I do use a lot of JavaScript. If you use a decent JavaScript toolkit, like for example jQuery, it's even faster and you hardly have to worry about it at all. For any nice advanced stuff you simply have to use JavaScript, and that's what it's there for. You want to disable JavaScript? That's fine by me, but you WILL be missing out. Really, what's next, catering to people who don't have CSS? Sure there are a lot of people who think sites should still work and look readable without CSS, but really, that depends on the market segment of the website. You can't make rich websites without CSS and JavaScript. Simple. Not every site can get away with looking like Google.com, it depends on the target audience and the content.

Firefox through Wine

[etymxris]

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.

The JIT compiler isn't in JavaScript yet.

[Animats]

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.

And the winner: Linux

[tcdk]

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...

It's Flash

[CrazedWalrus]

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?

Re:It's Flash

[cheater512]

Seamonkey + Flash on my old P3 laptop is fine.

If by fine you mean freaking bloody slow.
Flash designers wouldnt know speed if it slapped them with a large trout.

YouTube is good. It can handle a video pretty well (occasional frame dropping).
Ads and many other things will reduce the computer to a crawl instantly.

Compare JavaScript Frameworks

[Dekortage]

If you run the MooTools Slickspeed tests in different browsers, you find something interesting:

• jQuery is the fastest JavaScript framework in IE6 and 7, and the slowest in FireFox, and middle-of-the-pack in Safari.
• MooTools is the fastest in Firefox and Safari, and slowest in IE.
• Prototype is generally slower than the others, particularly in Safari, and frequently doesn't perform the tests correctly.

jQuery also claims to be the most accurate, though who knows for sure.

The actual problem...

[encoderer]

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 :)

Re:Opera

[ed.markovich]

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. I am just curious as to what you're talking about. I've been using Opera for a while now and have not noticed it having any JS issues.