[webkit-dev] setTimeout as browser speed throttle

Peter Kasting pkasting at chromium.org
Tue Sep 30 17:13:32 PDT 2008

On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> Can you cite some of the existing sites that would benefit? That would help
> others confirm the benefit and also estimate likelihood of said sites
> adopting a new better API for greater benefit.

how to make apps doing long-running calculations responsive by breaking them
into small chunks and using setTimeout(..., 0).  This is precisely the type
of pattern we hope to speed up.  On the sample page at
Chromium runs the test in about 1 sec, compared to ~15.6 sec in Safari 3.1.
 Even the "optimized" version at
still faster.

An obvious example is John Resig's timer perf bench at
http://ejohn.org/apps/timers/ , which I'm sure you're familiar with.  This
loads up about 15x faster since it uses setTimeout(..., 0).  One can argue
about the relative worth of this benchmark, of course, but then I seem to
remember from our last lunch that the WebKit team generally had the
philosophy of "speed up the benchmark regardless, and complain about the
validity of it in parallel if necessary" :)

These two are some of the most obvious cases, where loading the page takes
dramatically less time, but there are more subtle wins.  For
example, Chromium should save about 9 ms on
http://www.benya.com/code/jsbenchmarks/table-rendering-benchmarks.html due
to the uncapping.

A sample page which is theoretically, but seemingly not practically, helped
by this is http://hassing.org/projects/asteroids/ .  At least on my machine,
the CPU load is low enough that the difference between Safari's 100 FPS cap
and Chromium's 1000 FPS cap is unnoticeable.  I suppose that on a
slow/heavily loaded machine things might be different; not sure.

a pattern that will save a bit of time on some callbacks, but I
don't actually have a testcase where that sample code is used.

These few examples are what I had off the top of my head.  If you'd like, we
can do a more exhaustive search for affected pages and get back to you with
the results.  (The guy who has that data isn't around ATM.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/cbac3c67/attachment-0001.html 

More information about the webkit-dev mailing list