Skip navigation.
KDE Developer's Journals

Rendering Engines Benchmark

spart's picture

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 Smiling

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kevinkofler's picture

KHTML rulez!

I'm impressed by how KJS's bytecode interpreter (FrostByte) can outperform Google Chrome's JIT (V8) on a lot of testcases. Does this mean the overhead of compiling to native code is not worth it and interpreting is actually faster? Or is WebKit so slow that JITting doesn't help?

spart's picture

has hinted in the article, I

has hinted in the article, I think the answer is rather that you can't really consider JavaScript's speed in isolation on real world test cases.

In 90% of real applications JavaScript will trigger DOM changes, DOM changes will trigger CSS style recalculations, Style recalculations will maybe invalidate part of the View and thus trigger a repaint. There must not be any weakness along this line, or speed would suffer greatly.

dipesh's picture

Thanks

Great stuff that should be spread around a bit more. Konqi rocks Smiling
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?

spart's picture

Hi... I did not know that,

Hi... I did not know that, but it looks like a nice idea Smiling
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.

sad eagle's picture

Curious: when would it make

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

spart's picture

just external links I

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

sad eagle's picture

Ah, I see, on hover, I

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

kamikazow's picture

Lies, Damn Lies, and Benchmarks

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.

dipesh's picture

I wouldn't wonder if that was

I wouldn't wonder if that was fixed already Eye-wink

sad eagle's picture

Please file bug reports on

Please file bug reports on any slowness you encounter.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.