Hi Peter,
On Sep 30, 2008, at 8:42 PM, Peter Kasting wrote:
2008/9/30 Mike Belshe <[EMAIL PROTECTED]>
As for keeping the fan off - if we could keep the CPU idle a 3ms
minimum timeout loop does that resolve your concern?
Followup to my earlier post, based on this.
I realize that one reason why we (Chromium folks) have not been as
concerned about CPU usage is that in a multi-process world,
excessive CPU is an annoyance, but doesn't completely break the
app. This wouldn't necessarily be the case in a single-process
consumer of WebKit, e.g. Safari, where a page in a tight JS loop
could make the whole browser less responsive. This seems like a
legitimate reason to be concerned about excessive CPU usage. Mike's
suggestion that we can find a minimum timeout value (e.g. 3 ms)
where the CPU doesn't get pegged seems reasonable if this is the
main issue.
And a few more thoughts on app compat. Using more CPU is not an app
compat concern. The CG GIF decoder that Safari uses burns 10x the
CPU that Gecko's does, such that on various animated GIFs I can hit
60% of one of my (very fast!) cores just animating a single image in
Safari. But no one has ever presented this as a "web app compat"
issue, even though tons of web pages use animated GIFs; it's just a
bug/optimization opportunity. Chromium uses extra CPU due to having
plugins out of process. Gecko uses more CPU to relayout than
WebKit. None of these are compatibility issues. The comments on
bug 6998 imply to me that the 10ms cap was put in because Safari was
eating more CPU than other browsers, not because there were
animations running at the wrong speed or stylesheet loads not being
sensed soon enough.
I think if we can agree that not pegging the CPU, rather than
precisely matching other browsers (which is impossible due to their
60% variance from each other), is the chief objection to uncapped
timers, it will be easier to move forward.
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).
2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>
Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а):
> As for keeping the fan off - if we could keep the CPU idle a 3ms
> minimum timeout loop does that resolve your concern?
Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur
non-trivial processor usage.
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.
Take care,
Rob
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
