Webkit/V8 vs. Webkit/JavaScriptCore/SquirreFish, WOW

[Jorge]

Run the benchmarks at
http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
and
http://code.google.com/apis/v8/run.html

And see : V8 is between 8.5...13.8 times faster !

 

[Gregor Kofler]

Jorge meinte:

Run the benchmarks at
http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
and
http://code.google.com/apis/v8/run.html

And see : V8 is between 8.5...13.8 times faster !

Nope. V8 is 5 times slower than SpiderMonkey or Safari's JS Engine. At
least in my (undeniably pedestrian) benchmark. However, it tells me,
that most^Wall of those artificial benchmarks (particularly those
provided by browser developers) are crap.

And they always and only measure pure JS speed, never DOM "speed". Which
is precisely the same thing, as rating a computer system by pure CPU
muscles when using it as gaming platform.

Gregor

 

[Jorge]

And they always and only measure pure JS speed, never DOM "speed".

That's the main reason why they're called JS bechmarks, not DOM
benchmarks.
DOM speed has more to do with the layout/rendering engine than with
JS, I believe.

 

[Stanimir Stamenkov]

Sat, 6 Sep 2008 13:00:12 -0700 (PDT), /Jorge/:

That's the main reason why they're called JS bechmarks, not DOM
benchmarks.
DOM speed has more to do with the layout/rendering engine than with
JS, I believe.

DOM speed in this case is about manipulation of the DOM from
scripts. So if Safari's script engine performs much better with DOM
manipulation than Chrome's, then given they both use the same
layout/rendering engine Safari appears much better to me as this
what scripting on the Web is used mostly for.

My tests running SunSpider [1] using latest Firefox 3.1 nightly
(with the TraceMonkey JIT enabled [2]) and Chrome showed Firefox
performs better in overall and with most basic operations, where
Chrome shows better in less practical areas, IMO.

[1] http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
[2]
https://wiki.mozilla.org/JavaScript:TraceMonkey#Playing_with_TraceMonkey

 

[Gregor Kofler]

Jorge meinte:

That's the main reason why they're called JS bechmarks, not DOM
benchmarks.

Correct. Nontheless I deem them pretty useless. If you state that V8 is
10 times faster than other engines, it hardly says anything about how it
will affect the performance of ones web applications. After all, pure JS
without DOM interaction is rarely useful.

However, my supersimple benchmark[1] shows that sorting a simple row
takes, say, 30ms on Chrome, sorting a "complicated" table (dates) takes
130ms. On Safari the figures are 40/60ms on FF 270ms/300ms. Since the
DOM manipulation is always the same, FF obviously has its problems with
rearranging the table rows (in fact it gets a lot faster, if cells are
simple and don't contain input elements). When sorting date columns,
they get converted into ISO format before being sorted. The "normal"
text column omits this "pure JS" step.
That leads to the conclusion, that Chrome needs approx. 100ms for this
step, Safari 20ms and Firefox 30ms. Whatever the reasons are (perhaps
Array.sort() in Chrome is crap?), it shows the "value" of benchmarking.

BTW: My "benchmark" can at least claim, to be rooted in a "real world"
application.

Gregor


[1]
http://web.gregorkofler.com/index.php?page=sortable

 

[Jorge]

If you state that V8 is
10 times faster than other engines, it hardly says anything about how it
will affect the performance of ones web applications. After all, pure JS
without DOM interaction is rarely useful.

What you're saying is like if you put a gigabit enet card into an 8086
PC-XT server just to find out that it still performs as poorly as
before. Then you move to a four-cores core2/SATA RAID/16GB RAM linux
server and plug it in through a 10BaseT card because you've learned
that "gigabit enet is useless"...

There are several variables in the end-result equation, JS is one of
them. It's weight in the end result depends on the kind of page.

 

[Jorge]

However, my supersimple benchmark[1] shows that sorting a simple row
takes, say, 30ms on Chrome, sorting a "complicated" table (dates) takes
130ms. On Safari the figures are 40/60ms on FF 270ms/300ms. Since the
DOM manipulation is always the same, FF obviously has its problems with
rearranging the table rows (in fact it gets a lot faster, if cells are
simple and don't contain input elements). When sorting date columns,
they get converted into ISO format before being sorted. The "normal"
text column omits this "pure JS" step.
That leads to the conclusion, that Chrome needs approx. 100ms for this
step, Safari 20ms and Firefox 30ms. Whatever the reasons are (perhaps
Array.sort() in Chrome is crap?), it shows the "value" of benchmarking.

BTW: My "benchmark" can at least claim, to be rooted in a "real world"
application.

This page :

http://preview.tinyurl.com/685oh2

sorts a table and updates the screen in an endless loop and shows the
speed in loops (frames) per second.
The frame rates that I get:

FF 3.01: 21fps
Safari 3.1.2: 32fps
Opera 9.52: 51fps
Chrome: varies between 72fps ... 100fps (?)

 

[Gregor Kofler]

Jorge meinte:

This page :

http://preview.tinyurl.com/685oh2

sorts a table and updates the screen in an endless loop and shows the
speed in loops (frames) per second.
The frame rates that I get:

FF 3.01: 21fps
Safari 3.1.2: 32fps
Opera 9.52: 51fps
Chrome: varies between 72fps ... 100fps (?)

Yes. And? That doesn't contradict my findings. Your sort function looks
like that:

var sort1= function (pA, pB) { return pB[0]-pA[0] }

With this sort function Chrome is the fastest browser in my test, too
(though Safari comes in second, and the margin is much smaller).

Chrome gets slowed down more than other browser, when the comparison
function becomes more complex.

Gregor

 

[Jorge]

Yes. And?

And... nothing. I just wanted to put online a "tool" to benchmark
with.

That doesn't contradict my findings. Your sort function looks
like that:

var sort1= function (pA, pB) { return pB[0]-pA[0] }

With this sort function Chrome is the fastest browser in my test, too
(though Safari comes in second, and the margin is much smaller).

Chrome gets slowed down more than other browser, when the comparison
function becomes more complex.

That's weird, as here :

http://code.google.com/apis/v8/design.html

You can read :

"if the functions in your application tend to be run again and again,
the performance improvement will be greater than if many different
functions tend to run only once."

Unless that sorting f() uses regular expressions (?) :

"if your application does a lot of evaluating regular expressions, you
might not see much performance improvement"

What fps rates do you get ?

 

[Gregor Kofler]

Jorge meinte:

Unless that sorting f() uses regular expressions (?) :

"if your application does a lot of evaluating regular expressions, you
might not see much performance improvement"

My "complex" sorting uses regexp.

What fps rates do you get ?

FF 21, Opera 64, Chrome 81 (relatively stable), Safari 40.

Gregor

 

[Thomas 'PointedEars' Lahn]

Jorge jumped to conclusions with benchmarks again:

Run the benchmarks at
http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
and
http://code.google.com/apis/v8/run.html

And see : V8 is between 8.5...13.8 times faster !

Oh, please!


PointedEars