2008-09-02

Google Chrome Benchmarks

I know the blog-o-sphere is a-buzz about Google Chrome - but I have to add my own two-cents worth. I just happen to be in the last throes of editing my paper for the Digital World GEOWS 2009 conference. The paper explores geoprocessing performance in AJAX - which means I'm benchmarking JavaScript (ECMAScript?!?) engines in various browsers.

Chrome is the third new browser I've tested in the past week! I grabbed the pre-release of FireFox 3.1 and turned on the new TraceMonkey engine. I downloaded Internet Explorer 8 beta 2 as soon as it was available. And now, I've got Google Chrome!

I'm not sure if I'm allowed to share this... But here are the results:
From GEOWS


From GEOWS


What is this benchmark?

It's an implementation of the Ramer-Douglas-Peucker line simplification routine. It's a worst-case O(n^2) algorithm that gives reasonably good results for generating smaller scale representations of linear features. We ended up producing two versions of the implementation. The first uses an array to store the vertices and the second uses a linked-list. One of the things we found across most of the JavaScript interpreters is that arrays are usually handled as associative lists, so element access is worse than O(n) - which means any algorithm that uses alot of data would be slowed down an order or so just by the data type.

The benchmarks were all run on a 2.0Ghz Intel Core 2 Duo running Windows XP SP3. All unnecessary processes were stopped and the browsers were launched with a script, setting the process priority to "Realtime". The benchmarks were also run on an Apple Mac-Mini with the same 2.0Ghz Intel Core 2 Duo CPU and the current version of OS-X and Safari. The results for Safari on that platform were almost identical to the results for Safari on my Windows XP platform (if you really need to know, the Mac was slightly slower on the test - but that might have had to do with my not being able to control background processes on the machine at the Apple Store!).

The numbers for Safari and Chrome show that their JavaScript implementations reduce this problem. In fact, Safari ran the array implementation faster than the linked-list implementation.

The pre-release of FireFox 3.1 really screamed through the first few iterations at the higher vertex counts but slowed back down to 3.0 speeds soon after. This behavior was perfectly repeatable. I'll be that the final TraceMonkey will maintain the higher performance through the entire test.

IE8 Beta 2 generally sucked. It was much better than Beta 1 but still the slow poke. While the rest of the world is busy improving their AJAX performance by leaps and bounds, Microsoft appears mired in it's own dog food.

I have some other benchmarks that provide a synthetic test of array implementations. I'm not going to post them here because I really don't know if they show anything meaningful. The RDP tests actually DO something with the data structures. I will say, however, that Safari's performance on the synthetic benchmarks bore out the conclusion that Safari's array handling absolutely smokes everyone else.

Watch for the paper in the IARIA GEOWS 2009 conference proceedings.

Oh yeah... I should mention that as a big Google fan (this post uses Blogger and PicasaWeb), the performance in Gmail and Google Docs is flat out impressive.