A New JavaScript Benchmark From the WebKit Team

Here in WebKit-land, we strive for great performance and we love to make things faster. When doing performance work, it’s critical to be able to measure how fast you are at any given time and track changes. And it’s important to make sure your metric reflects realistic use cases. None of the existing JavaScript benchmarks were exactly suited to our needs (more on that below), so we decided to make our own.

We’re widely announcing this benchmark today because we’d like to share with other browser-hosted and standalone JavaScript engines. And we’d like to have input from JavaScript experts on the usefulness and validity of the tests. In that spirit of cooperation, we’re not going to post competitive numbers or even comparisons to older Safari/WebKit versions for now (although I can tell you that the shipping version of Safari 3 is not the fastest JS engine we tested).

But people like playing with these benchmarks. So I’m sure a lot of you would like to try your luck and test your browser. If you’d like to post your results in the comments, please mention what browser, what version, and what hardware and OS you’re running on. Make sure to quit extraneous apps and avoid jiggling your mouse for the minute or two that it runs. Have fun!

The Gory Details

There are a lot of JavaScript benchmarks out there already: Celtic Kane’s JavaScript speed test, the JavaScript processing test from iBench, Jason Orendorff’s JavaScript speed tests, John Resig’s tests, and others. But none of these were quite what we needed to measure improve real-world JavaScript performance.

So we made our own. Why bother? Well, we think our benchmark has a combination of useful properties that we didn’t see in any existing test:

It’s based on real code that does interesting things; both things that the web apps of today are doing, and more advanced code of the sorts we can expect as web apps become more advanced. Very few of the tests could be classed as microbenchmarks.

It’s balanced between different aspects of the JavaScript language — not dominated by just a small handful of different things. In fact, we collected test cases from all over the web, including from other benchmarks. But at the same time, we avoided DOM tests and stuck to the core JavaScript language itself.

It’s super easy to run in the browser or from the command line, so you can test both pure engine performance, and the results you actually get in the browser.

We included statistical analysis so you can see how stable the results you’re getting really are.

Incidentally, we’ve been doing a lot of work on JavaScript performance lately. If you’re interested in helping out, stop by the webkit-dev@webkit.org mailing list, or the #webkit IRC channel on chat.freenode.net and say hi. Our engine is highly hackable so it’s easier than you think to get started.