[webkit-dev] setTimeout as browser speed throttle

[Maciej Stachowiak]

On Sep 30, 2008, at 6:37 PM, Peter Kasting wrote:

> On Tue, Sep 30, 2008 at 5:31 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
> 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?
>
> You're right; my list sucked.  I thought we had a list of sites that  
> were helped that led us to do this and posted assuming that without  
> checking.  I shouldn't have asserted something I hadn't verified,  
> and I should have said so immediately afterwards.  I'm sorry.
>
> I think our original motivation was that we wrote some code very  
> like the benchmarks Mike posted to start this thread, and found  
> things were unexpectedly slow.  We hadn't realized there'd be a  
> minimum value on setTimeout() since there wasn't a spec that said  
> that and it wasn't intuitive that there should be one; if we had  
> made this mistake, surely others would have, so we wondered if we  
> could improve things for people in general.  When we considered  
> lowering it we worried quite a bit about web compat, but were unable  
> to find any problems in several months of daily usage, or in our  
> explicit testing of all the related sites we could find from old  
> WebKit bugs about this.  And since launch I believe we still haven't  
> seen problems of sites intentionally using setTimeout(0) and having  
> difficulties; the one problem I'm aware of involves double-inclusion  
> of a script that leads to an orphaned timer spinning in the  
> background.  But I'm not sure, maybe there have been other cases we  
> know of.
>
> I still think this is the right thing to do, though I don't seem to  
> have any convincing evidence for it.  Darin's comments on bug 6998,  
> or John Resig's comments on his blog post about Chromium's behavior  
> here, or Hyatt's comments earlier in this thread, echo parts of my  
> feelings, which are: authors should be able to get called back  
> "ASAP" when they do this, where "ASAP" is subject to the limits of  
> the platform, not burning 100% of the CPU, etc.  I assume there are  
> sites out there that legitimately benefit from our changes, but I  
> think we made our decision before having such a list.
>
> So I am sorry for being so forceful with this opinion previously and  
> that I don't have good data to support it.  We (the Chromium folks)  
> want to help make the web better and it seems like we've been  
> getting off on the wrong foot a lot lately in broader WebKit  
> discussions, but I hope you will still consider our opinions  
> seriously.  Sometimes we have acted on instinct, theory, and limited  
> data, but I'm not sure that that means all of those decisions have  
> been wrong.

That's ok, we are used to some forceful assertion of opinions in the  
WebKit community. :-) As long as we can ultimately come to a good  
resolution, it's ok if the discussion goes off on some tangents.  
Indeed, I think a lot of good ideas and information have come up in  
this thread, and I am glad that we had this discussion. This list  
should be a safe space for freewheeling (but respectful) technical  
discussions.

But on the other hand, In the history of WebKit development we have a  
strong tradition of using data, measurements and testing to evaluate  
changes, particularly in the areas of performance, memory use and Web  
compatibility. Our experience with performance especially is that  
improvements based on guesswork or instinct rather than measurement  
tend to be ineffective. One advantage of data and measurements is that  
they tend to be easier for a heterogenous organization to agree on  
than theories or instincts.


I agree with you that web content authors should have a way to get  
called back ASAP. It seems like we have three different proposals  
identified that most have agreed are worth pursuing:

1) Design an improved timer API that is object-oriented and supports  
high resolution, with no artificial lower limit. Propose for HTML5,  
implement in WebKit, encourage other browser vendors to implement it.  
Am I right that there's rough consensus we should do this? If so, I  
can circulate a rough cut proposal on this list, and then move  
discussion of this idea to the WHATWG.

2) Consider making WebKit's default minimum timer limit lower -  
something like 3ms-5ms. I don't know what we would do to verify that  
this is "safe enough" or who would do the work. Maybe Hyatt?

3) Determine whether other browser vendors would be willing to change  
the minimum timeout for setTimeout and setInterval (which would not  
eliminate the risk with legacy content but would reduce its severity  
over time). If others agree this is worth pursuing, I can at least ask  
on the HTML WG mailing list.

Thoughts?


Regards,
Maciej

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