On Tue, Sep 30, 2008 at 12:17 PM, Rob Burns <[EMAIL PROTECTED]> 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev