[webkit-dev] setTimeout as browser speed throttle

[Oliver Hunt]

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.

Um, if you have a complex function that you break up into interval  
that are too short it's going to cause poor performance -- it's just  
bad code simply put, and helping badly written code is not something  
that makes much sense (to me at least).  Alternatively if you look at http://nerget.com/rayjs3/rayjs.html 
  you'll see it varies the amount of computation it does in each pass  
based on an educated guess as to how much work it can do in a  
reasonable amount of time, rather than just taking the most  
conservative approach possible and allowing the timeout delay to be  
larger than the computation time.

>
> 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" :)

The purpose of John's tests was to compare reliability and stability  
of each browser's timer implementation -- it's not a performance  
benchmark in the traditional sense.

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