2009/6/24 Evan Martin <e...@chromium.org>
>
>
> http://www.codexon.com/posts/a-real-benchmark-real-websites-with-chrome-firefox-opera-safari-ie
>
> Brief summary:
> - measures warm-disk-based snapshots of real websites
> - hand-injected <script src> into pages that uses
> addEventListener("load") / attachEvent("onload") to tell when load is
> done (I wonder if parallel script loading plays into it?)
> - statistical methodology isn't the greatest
> - concludes with a three-way tie between Chrome, Safari, and Opera
>
> Both Chrome and Safari are similarly significantly slower (around
> 200ms over IE/FF/Opera) for their Baidu test.
> WebKit bug or measuring bug?
There's a remote chance that Chrome 2.0.x is on par with IE/FF/Opera if it's
due to a webkit unforking we did that I have yet to make it again in the
webkit trunk. However, an order of magnitude difference seems way too much
(we certainly only saw a small spike, if any, in intl1 page cycler test
IIRC). If that's indeed the cause (although not very likely), I may have an
easier time with the upstream :-)
More likely is that the tester's machine does not have any Chinese font or
only one (e.g. Arial Unicode MS) and webkit win is slower in that scenario.
Hmm, but his OS is Vista which I think is preloaded with Chinese fonts (it
may depend on the 'flavor'??).
Jungshik
>
> This makes me wonder if it'd be helpful for us to publish a blog post
> on "how to do a benchmark". Would mention stuff like whether
> DOMContentReady includes image loads completion on all browsers (I
> certainly don't know), geometric mean vs arithmetic mean, whether we
> expect networking stacks to have an impact on real perf, etc.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
