[webkit-dev] setTimeout as browser speed throttle

[Maciej Stachowiak]

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>  
> 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.
>
> Sure.   http://ajaxian.com/archives/running-cpu-intensive-javascript-computations-in-a-web-browser 
>  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  
> to speed up.  On the sample page at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process.html 
>  , Chromium runs the test in about 1 sec, compared to ~15.6 sec in  
> Safari 3.1.  Even the "optimized" version at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process-optimized.html 
>  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.

Regards,
Maciej





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