SEP
29
2008

Rendering Engines Benchmark

Ever since Maksim Orlovich released benchmarks of its excellent FrostByte flavour of the KJS engine, I've been curious to perform a synthetic benchmark of KHTML/KJS, to see what our whole stack is up to.

There would indeed be little point in having a smoking fast JavaScript engine if performance was going to fall apart at the next link of the chain, such as in DOM tree manipulation or Rendering, wouldn't it?

Well, what better time for conducting tests than now, at the eve of the KDE 4.1.2 release, where new generation browsers are stable and some new contenders want to enter the field...

I will therefore present results for the following engines/browsers :

  • KHTML/KJS on Konqueror 4.1.2
  • Presto/Futhark on Opera 9.52
  • Gecko/SpiderMonkey on Firefox 3.0.1
  • WebCore/V8 on Chrome 0.2.149.27(beta)/wine 1.1.4
  • QWebkit on Qt 4.4's Demo Browser

As for the tests themselves, I did not want to bias this benchmark by crafting them specially, so I decided to use the readily available synthetic performance test suite, consisting of a patchwork of external tests, that was independantly set together for testing the performance of Opera 9.5.

Before I proceed to the details, I am very happy to report up front that KHTML/KJS is the engine that showed the most consistent performance, and is definetly the fastest overall on the Linux IA-32 platform :-)

There are six tests available, that I will examine successively. Each test was run three times on an otherwise idle AMD X2 4600+ with 2 Gigabytes of ram; the arithmetic mean of those was kept as final result.

The first test is a JavaScript driven raytracer that is very nice for stressing evenly the JS, DOM and Rendering stack. It is therefore a good representation of DHTML performances:


KHTML scores a gold, Chrome a silver and Opera a bronze.

(as a side note, this really is a nice reward for all the work put in the careful optimisation of DHTML in our rendering engine - such as in direct layer translation, and deep optimisation of the positioned objects code path)

The second test is pure JavaScript computation :


Gold is for Chrome, silver for Gecko and bronze for KHTML.

The 3D cube test is majorly JavaScript, but with a significant Rendering component :


Chrome has the gold, KHTML the silver, and bronze goes to Gecko

The fourth test is also pure JavaScript, but with a DOM component:


Opera wins the gold, KHTML takes silver and Chrome is happy to go with bronze.

The fith test is for pure DOM manipulations :


KHTML takes the gold, Chrome is silver and Opera bronze.

The sixth is a batch of four tests aiming at testing the rendering speed of standard html elements, and of the very young Canvas element. It stresses both the DOM and either the HTML rendering stack or the Canvas painting stack (so it would probably make more sense to separate this latter test from the others but hey..)


Gecko scores a gold, Opera a silver and KHTML a bronze

Our bronze here shows off the work of Harri Porten, who contributed significant DOM speed ups and other optimisations.

Greetings,
Germain

Comments

Nice work there guys, you have an impressive Javascript interpreter there!

However unfortunately I don't use Konqueror and the Javascript performance isn't why. Until you can either get 1:1 rendering compatibility with either Firefox or Safari (bugs and all) or you get the majority of the web designers out there testing against Konqueror (sadly, not going to happen) a lot of people simply won't use Konqueror.


By Mike Arthur at Mon, 09/29/2008 - 15:23

Mike, I see your point. Don't forget about two aspects though:

1.) there is no browser that is 1:1 compatible to any other browser. That includes different versions or platform ports of the same browser. So that's not a realistic goal.

2.) following this logic this best thing would be to go after IE compatibility (which we often enough try to minmick) given its market share. But then, KDE is a cross-platform environment and therefore will never be be able to have Windows-specific characteristics and therefore is not suitable as a platform.

I'm just glad that the founders of KDE did not get scared away by such concerns as we wouldn't have this lovely project available to us today :)


By harri at Mon, 09/29/2008 - 16:03

So your benchmarks tell that Konqueror is among the fastest browser. Great, but why is it so damn slow in may daily browsing habits? WebKit browsers (Safari and Arora) and Firefox 3 are definitely faster.


By kamikazow at Mon, 09/29/2008 - 17:01

Please file bug reports on any slowness you encounter.


By Maksim Orlovich at Mon, 09/29/2008 - 18:06

I wouldn't wonder if that was fixed already ;)


By Sebastian Sauer at Mon, 09/29/2008 - 20:44

Great stuff that should be spread around a bit more. Konqi rocks :)
A smaller question; some time ago I did read that chrome will work optional with some kind of DNS-prefetch what may decrease the time needed to load+display something noteable. Anything planed in that direction?


By Sebastian Sauer at Mon, 09/29/2008 - 21:02

Hi... I did not know that, but it looks like a nice idea :)
And it is in fact quite easy to implement.
I just did a 10 lines proof of concept using kio's private dns cache... seem to work fine.
I'm not sure it buys so much time here though, but I guess in some slow dns set up it could shave off 250ms or something.


By spart at Tue, 09/30/2008 - 13:04

Curious: when would it make sense to pre-fetch DNS data and not actual data?


By Maksim Orlovich at Tue, 09/30/2008 - 14:28

just external links I think...
<a href="http://www.somewhere.org">link I might click on later on</a>


By spart at Tue, 09/30/2008 - 16:40

Ah, I see, on hover, I presume? Seems like a minor privacy leak, though.

... This reminds me, though, I need to do a patch for Qt's certificate loading code, which is woefully inefficient and can slow kio_http startup significantly on slower machines (can be as much as a half of a second or so when my laptop is initially clocked down...)


By Maksim Orlovich at Wed, 10/01/2008 - 16:02

Pages