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.
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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
