[webkit-dev] setTimeout as browser speed throttle
mjs at apple.com
Tue Sep 30 17:31:45 PDT 2008
On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote:
> On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak <mjs at apple.com>
> 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.
> describes 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
> , Chromium runs the test in about 1 sec, compared to ~15.6 sec in
> is 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.
> Similarly, http://cometdaily.com/2008/08/11/robust-network-code-with-windowsettimeout/
> describes 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.)
It seems to these are demo pages, tutorials, or descriptions of
techniques. Clearly tutorials and demos can adapt to a new API, and
improving their current form is not much of a benefit. How about real
existing sites that benefit? That is what you cited that as the
justification for changing the existing setTimeout / setInterval APIs,
rather than relying solely on new API.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev