On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote:
On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
