<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Peter,<div><br><div><div>On Sep 30, 2008, at 8:42 PM, Peter Kasting wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">2008/9/30 Mike Belshe <span dir="ltr">&lt;<a href="mailto:mike@belshe.com">mike@belshe.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div dir="ltr"><div>As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern?</div></div></blockquote><div><br></div><div>Followup to my earlier post, based on this.</div> <div><br></div><div>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. &nbsp;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. &nbsp;This seems like a legitimate reason to be concerned about excessive CPU usage. &nbsp;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.</div> <div><br></div><div>And a few more thoughts on app compat. &nbsp;Using more CPU is not an app compat concern. &nbsp;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. &nbsp;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. &nbsp;Chromium uses extra CPU due to having plugins out of process. &nbsp;Gecko uses more CPU to relayout than WebKit. &nbsp;None of these are compatibility issues. &nbsp;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.</div> <div><br></div><div>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.</div></div></div></blockquote><div><br></div>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).<br><br></div><div><blockquote type="cite">2008/9/30 Alexey Proskuryakov&nbsp;<span dir="ltr">&lt;<a href="mailto:ap@webkit.org">ap@webkit.org</a>></span><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а):<br><div class="Ih2E3d">> As for keeping the fan off - if we could keep the CPU idle a 3ms<br>> minimum timeout loop does that resolve your concern?<br><br></div>Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur<br>non-trivial processor usage.<br><div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br></div><div>Your comment in that bug was that it was 3.7% of CPU on your machine. &nbsp;3.7% for "as fast as possible" doesn't seem like a huge burden. &nbsp;That suggests authors could write tight loops at 3ms delays and still only burn 10% of the CPU. &nbsp;I think that's a reasonable proposal.</div></blockquote><br></div><div>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.</div><div><br></div><div>Take care,</div><div>Rob</div></div></body></html>