[webkit-dev] setTimeout as browser speed throttle
hyatt at apple.com
Wed Oct 1 10:38:51 PDT 2008
I think we should be shooting for a target clamp value of 3-5ms.
On Oct 1, 2008, at 12:02 PM, Linus Upson wrote:
> We can use the histogram facility in chrome to collect data from a dev
> channel release. It should only take a few weeks to get good data.
> What exactly do we want to measure to settle on a value?
> On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak <mjs at apple.com>
>> On Oct 1, 2008, at 1:24 AM, David Hyatt wrote:
>> On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote:
>> I can appreciate that you aren't interested in revisiting this
>> problem after
>> having resolved it finally by adding the clamp. I believe you when
>> you say
>> you had compelling evidence too.
>> We are interested in revisiting the problem or we wouldn't be
>> suggesting a
>> new high resolution timer API.
>> I'm with Hyatt. The reason we are having this thread is precisely
>> to revisit
>> the problem.
>> I don't know how clear I was in the previous email, but basically
>> it can
>> take a lot of time before you see problems. What happens is a site
>> makes a
>> change, screws up and puts in an unintentional setTimeout loop, and
>> they pwn the CPU of a browser with no clamp. They don't discover
>> it because
>> every browser has a pretty high clamp. When we had these issues,
>> basically crop up one site at a time every so often. The good news
>> is that
>> usually the sites would fix the problems, but the bad news is it
>> could take
>> a while, and angry users would be switching to Firefox.
>> That is what I was alluding to when I said it took us 3.5 years to
>> realize we had to add the clamp. The problems come and go, but they
>> consistently a problem, and it can take a while to realize it.
>> However, the bug Mike cited seems to mention problems with the 1ms
>> limit on
>> some real sites:
>> <http://code.google.com/p/chromium/issues/detail?id=792>. At least
>> 5 sites
>> are mentioned, including nytimes.
>> I think we are converging on some good solutions (somewhat lower
>> clamp, new highres API) and I regret if this thread has felt
>> hostile to
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
More information about the webkit-dev