[webkit-dev] setTimeout as browser speed throttle
pkasting at chromium.org
Tue Sep 30 13:19:23 PDT 2008
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev