<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div style="word-wrap:break-word"><div><div>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.</div> </div></div></blockquote><div><br></div><div>Sure. &nbsp; <a href="http://ajaxian.com/archives/running-cpu-intensive-javascript-computations-in-a-web-browser">http://ajaxian.com/archives/running-cpu-intensive-javascript-computations-in-a-web-browser</a>&nbsp;describes how to make apps doing long-running calculations responsive by breaking them into small chunks and using setTimeout(..., 0). &nbsp;This is precisely the type of pattern we hope to speed up. &nbsp;On the sample page at&nbsp;<a href="http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process.html">http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process.html</a>&nbsp;, Chromium runs the test in about 1 sec, compared to ~15.6 sec in Safari 3.1. &nbsp;Even the "optimized" version at&nbsp;<a href="http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process-optimized.html">http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process-optimized.html</a> is still faster.</div> <div><br></div><div>An obvious example is John Resig's timer perf bench at&nbsp;<a href="http://ejohn.org/apps/timers/">http://ejohn.org/apps/timers/</a> , which I'm sure you're familiar with. &nbsp;This loads up about 15x faster since it uses setTimeout(..., 0). &nbsp;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" :)</div> <div><br></div><div>These two are some of the most obvious cases, where loading the page takes dramatically less time, but there are more subtle wins. &nbsp;For example,&nbsp;Chromium should save about 9 ms on&nbsp;<a href="http://www.benya.com/code/jsbenchmarks/table-rendering-benchmarks.html">http://www.benya.com/code/jsbenchmarks/table-rendering-benchmarks.html</a> due to the uncapping.</div> <div><br></div><div>A sample page which is theoretically, but seemingly not practically, helped by this is&nbsp;<a href="http://hassing.org/projects/asteroids/">http://hassing.org/projects/asteroids/</a>&nbsp;. &nbsp;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. &nbsp;I suppose that on a slow/heavily loaded machine things might be different; not sure.</div> <div><br></div><div>Similarly,&nbsp;<a href="http://cometdaily.com/2008/08/11/robust-network-code-with-windowsettimeout/">http://cometdaily.com/2008/08/11/robust-network-code-with-windowsettimeout/</a> 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.</div> <div><br></div><div>These few examples are what I had off the top of my head. &nbsp;If you'd like, we can do a more exhaustive search for affected pages and get back to you with the results. &nbsp;(The guy who has that data isn't around ATM.)</div></div></div></blockquote><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>