The Great Browser JavaScript Showdown

============================================
RESULTS (means and 95% confidence intervals)

I have to agree with these results. We have two workloads where we notice that IE is much slower than FF: 1. Google maps with lots of pointers. 2. dhtmlXgrid with lots of rows. IE is quite a bit slower.

I have no experience of any javascript, so I am only going by what I’ve read, but it is a shame there are incompatabilities in functionality across the javascript implementations. Will adopting strict ECMAscript fix that? Is there a standard DOM that could fix it? I hope so, except that I like the light user interface in Hotmail via Opera.

Any one here know javascripting pls help me…
the problem is there is a two radio button for cash and card mode of payment. if you selected cash it subtracted 5% of the amout and if card add 10% of original amount hepl pls.

Yes really great.I think I must learn more about javascript. Thanks.

@Jeff:

You said “I will never understand why Firefox doesn’t offer a 64-bit version. I’m sure it’d be even speedier!” … this makes no sense. Why would a 64-Bit version be speedier? This sounds a lot like marketing BLAH.

64-Bit is not speedier than 32-Bit, why would it? A 64 Bit version has a larger VM space for the app, the 32-Bit one is limited to 4 GB. But how close does FF get to that limit? My FF2 doesn’t even get to using one half GB of the VM (Virtual Memory BTW, not Virtual Machine) space. And that’s still FF2, FF3 uses much less memory. So no improvement here.

Okay, 64-Bit code can add, multiply, divide or substract two 64-Bit values with one operation, 32-Bit code needs more than one (three or four). Well, fair enough - but about 90% of all numbers used anywhere in code or on the a webpage are 32 Bit numbers. 32 Bit operations are equally fast in either version, actually chances are that 32 Bit operations are actually slower in 64 Bit code (just like 16 Bit operaitons are slower in 32 Bit code as they used to be in 16 Bit code). The Java Benchmark surely does not use a lot of 64 Bit values.

Last but not least, the 64 Bit Code can use more registers - but that is not true for 64 Bit code per se. It is only true because the x64 implementations of AMD and Intel do offer more registers in 64 Bit mode. So this is the only thing that can cause a speed improvement. However, the truth is, registers are much less important than we think they are. The PPC had 16 (compared to 6 on Intel) and did that lead to faster program code, I don’t think so. Actually you don’t need that many registers as you can use the stack and always free up registers as needed (push eax; - eax is now useable again, later, when needing the old value pop eax) Not only that push/pop are so highly optimized operations in modern CPUs that they are ultra fast - many people say “Hey, what about memory latency?” - you don’t really expect that push eax writes the EAX content really to memory, do you? It does not even write it to second level cache. Actually the value will stay in first level cache directly on the CPU die and first level cache accesses are only a little bit slower than register access. So just having a couple more registers will certainly never buy you more than 5% on any code on any system, unless you write the assembly code by hand and make perfect usage of the available registers. However, since most software uses a compiler (C or C++) nowadays, the compiler register distribution will never lead to equally perfect results as hand optimization and the code will thus not really benefit a lot from the few registers.

Other than that, there is no difference between 32 and 64 Bit code, so I doubt you will see it getting much speedier.

I’ve done a new benchmark though it’s not as shiny. It covers a lot more browsers, including 64-bit versions of Opera and Internet Explorer. Platforms covered are Windows, Linux, Mac OS X, and OpenSolaris.

http://www.carcinogenic-studios.com/sunspider-javascript-benchmark.html

Thanks!

Opera 9.51 Win XP32 AMD64 x2 4600:

Total: 8674.0ms +/- 0.9%

Google Chrome 0.2.149.27 on Dell Latitude D610, Windows XP32 SP3

============================================
RESULTS (means and 95% confidence intervals)

Safari Is Fastest Than Other Browser .

We Are Compare The New Version Of FF3 , Chrome , … , They All Have New Verion , And They Can Now To Get Fast Speed , But Safari Lastet Version Is From 109 Days Ago , Now What Is Fastest Than Other ?

============================================
RESULTS (means and 95% confidence intervals)

Linux 2.6.28 64bit, Firefox 3.5 Preview, TraceMonkey Engine,
12GB DDR3-RAM, Intel Core i7 920 @ 3.8 Ghz

============================================
RESULTS (means and 95% confidence intervals)

Great article - thanks! It is so important for people to do their homework when starting domain development. If you’re interested in learning even more, here is another great site to visit http://BeyondDomaining.com

In The Day Performance Didn’t Matter Any More, I found that the performance of JavaScript improved a hundredfold between 1996 and 2006. If Web 2.0 is built on a backbone of JavaScript, it’s largely possible only because of those crucial Moore’s Law performance improvements.

Since JavaScript is interpreted, loosely-typed, and may be hosted in varying environments, each incompatible with the others, a programmer has to take extra care to make sure the code executes as expected in as wide a range of circumstances as possible, and that functionality degrades gracefully when it does not.

Opera fanboi here, loving the attention Opera is getting! Actually I’m writing this from Safari on XP because with light font smoothing on my 21" CRT at 1600x1200 it is much easier to read large amounts of text. Unfortunately the user interface is terrible compared to the slickness of Opera’s mouse gestures, speed-dial, fast-forward, paste-and-go, icons in tabs, no close button in tabs if you want, and possibly most importantly: turn off gif animation.

I have no experience of any javascript, so I am only going by what I’ve read, but it is a shame there are incompatabilities in functionality across the javascript implementations. Will adopting strict ECMAscript fix that? Is there a standard DOM that could fix it? I hope so, except that I like the light user interface in Hotmail via Opera.

that is indeed a weird 2nd chart. It may need to be split into 9 charts, or put the bars for each browser side-by-side (9 charts in one) instead of stacking.

which coincidentally summarizes my opinion of Opera. Great when it works!
You could honestly say the exact same thing about Safari. If people don’t test for a browser it might not work, so both Safari and Opera gets shafted by this. This test happened to be written by Apple so it works in Safari and not Opera, if someone wrote a test to compare Ie/FF it might just as well not work in either of the two others.

My personal experience is that if it works in FF it almost always works in Opera (and vice versa), some sites are still IE Quirksmode only though.

Things get really messy once you involve heavy ajax stuff though, performance and fluidity suddenly depends on so much more, from plain up how fast the dom is to how the browser repaints. Makes me happy I don’t have to html/javascript anymore.

I did at test with my opera 9.24 and got 12124.4ms before reading that you couldn’t get any result at all. I’m not sure why we get different results however. Btw my computer is a slower amd64x2 3800+ with 2gb ram running xp.
As a comparison IE7 got 55196.6ms.