[webkit-dev] setTimeout as browser speed throttle

[Peter Kasting]

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.

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