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

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?


By Kevin Kofler at Tue, 09/30/2008 - 04:40

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.


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

Pages