[webkit-dev] setTimeout as browser speed throttle

[Peter Kasting]

On Tue, Sep 30, 2008 at 12:17 PM, Rob Burns <robburns1 at mac.com> wrote:

> The problem is not only confined to single processor systems. As others
> have mentioned the bigger problem is the waste of resources. The length of
> the timeout is not the full piece of the puzzle. There's also problems with
> what the application does at the end of each timeout. This often needless
> processor use ends up draining batteries, increasing heat and wasting energy
> (even with a multiprocessor system).
>

I never said there was no problem at all.  I said the problem was not a web
compat issue, and therefore not one on which all browsers were required to
agree.  It's a prolem, but a narrowly-scoped one, such that tradeoffs are
possible.

Your comment in that bug was that it was 3.7% of CPU on your machine.  3.7%
> for "as fast as possible" doesn't seem like a huge burden.  That suggests
> authors could write tight loops at 3ms delays and still only burn 10% of the
> CPU.  I think that's a reasonable proposal.
>
>
> Again, the length of the timeout is not the only thing determining CPU
> usage. The response to the timeout also influences CPU usage. If the timeout
> is clamped at 3ms instead of 12ms, then it is using the processor 4X as much
> (assuming that it doesn't also introduce synchronization problems the author
> didn't anticipate). That is quite significant. Given the growing importance
> in mobile processing it seems rather irresponsible to promote this waste of
> processor resources.
>

But again, 4x as much as what?  3 ms as opposed to 10 ms is ~3x as much CPU
usage as something that used 3.7% of CPU on a machine two years ago.   This
is roughly what Moore's Law has already given you back.  And I hardly think
it "promotes a waste of processor resources" to give apps the CPU they're
explicitly asking for since, as I've said, nearly every case we've run into
is a case where authors _want_ as much responsiveness as possible.

FWIW, I'm in favor of an additional API alongside this one if it enables
fully-uncapped timers and higher resolution than 1 ms -- but I don't think
that changes the argument for also lowering the cap on setTimeout().  If
taking ggaren's object-oriented suggestions into account makes life easier
on JS library authors then I'm for that too.

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