Webkit/V8 vs. Webkit/JavaScriptCore/SquirreFish, WOW
Jorge
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 !
--
Jorge.
Gregor Kofler
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
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
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.
--
Jorge.
Stanimir Stamenkov
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
--
Stanimir
Gregor Kofler
> On Sep 6, 8:23 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>
>> 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.
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.
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 (?)
--
Jorge.
Gregor Kofler
> 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 ?
--
Jorge.
Gregor Kofler
> 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.
Thomas 'PointedEars' Lahn
Oh, please!
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>