We do this now. We detect repeated setTimeouts and ratchet up to 10ms only after a repeated firing situation has been detected.
On Sep 30, 2008, at 9:48 AM, Dave Cronk wrote: > When I use setTimeouts, often the event has already occurred. So > rather than clamping, I'd suggest increasing the timeout up to 10ms > rather than clamping it at the start. Thus, if I specify 0, an > immediate check would occur, then move it up each time, maybe 1, 5, > 10 would be optimum. > > On Monday, September 29, 2008, at 10:58PM, "David Hyatt" <[EMAIL PROTECTED] > > wrote: >> We encountered 100% CPU spins on amazon.com, orbitz.com, >> mapquest.com, >> among others (looking through Radar histories). This was pre-clamp. >> Web sites make this mistake because they don't know any better, and >> it >> works fine in IE. It is a mistake these sites will continue to make, >> and Chrome is the only browser that will be susceptible. Being >> different from IE here is not a good thing. You will end up having >> to >> evangelize sites over and over to fix 100% CPU spins that occur only >> in your browser. Do you really want that kind of headache? >> >> A new API will let Web apps get the performance they need while >> avoiding compatibility problems. >> >> dave >> >> On Sep 29, 2008, at 10:06 PM, Maciej Stachowiak wrote: >> >>> >>> On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote: >>> >>>> Hi, >>>> >>>> One of the differences between Chrome and Safari is that Chrome >>>> sets the setTimeout clamp to 1ms as opposed to 10ms. This means >>>> that if the application writer requests a timer of less than 10ms, >>>> Chrome will allow it, whereas Safari will clamp the minimum timeout >>>> to 10ms. The reason we did this was to minimize browser delays >>>> when running graphical javascript applications. >>>> >>>> This has been a concern for some, so I wanted to bring it up here >>>> and get an open discussion going. My hope is to lower or remove >>>> the clamp over time. >>>> >>>> To demonstrate the benefit, here is one test case which benefits >>>> from removing the setTimeout clamp. Chrome gets about a ~4x >>>> performance boost by reducing the setTimeout clamp. This >>>> programming pattern in javascript is very common. >>>> >>>> http://www.belshe.com/test/sort/sort.html >>>> >>>> One counter argument brought up is a claim that all other browsers >>>> use a 10ms clamp, and this might cause incompatibilities. However, >>>> it turns out that browsers already use widely varying values. >>> >>> I believe all major browsers (besides Chrome) have a minimum of >>> either 10ms or 15.6ms. I don't think this is "widely varying". >>> >>>> We also really haven't seen any incompatibilities due to this >>>> change. It is true that having a lower clamp can provide an easy >>>> way for web developers to accidentally spin the CPU, and we have >>>> seen one high-profile instance of this. But of course spinning the >>>> CPU can be done in javascript all by itself :-) >>> >>> The kinds of problems we are concerned about are of three forms: >>> >>> 1) Animations that run faster than intended by the author (it's true >>> that 10ms vs 16ms floors will give slight differences in speed, but >>> not nearly as much so as 10ms vs no delay). >>> >>> 2) Burning CPU and battery on pages where the author did not expect >>> this to happen, and had not seen it on the browsers he or she has >>> tested with. >>> >>> 3) Possibly slowing things dow if a page is using a 0-delay timer to >>> poll for completion of network activity. The popular JavaScript >>> library jQuery does this to detect when all stylesheets have loaded. >>> Lack of clamping could actually slow down the loading it is intended >>> to wait for. >>> >>> 4) Future content that is authored in one of Safari or Chrome that >>> depends on timing of 0-delay timers will have different behavior in >>> the other. Thus, we get less compatibility benefit for WebKit-based >>> browsers through cross-testing. >>> >>> The fact that you say you have seen one high-profile instance >>> doesn't sound to me like there are no incompatibilities. It sounds >>> like there are some, and you have encountered at least one of them. >>> Points 1 and 2 are what made us add the timer minimum in the first >>> place, as documented in WebKit's SVN history and ChangeLogs. We >>> originally did not have one, and added it for compatibility with >>> other browsers. >>> >>> Currently Chrome gets an advantage on some benchmarks by accepting >>> this compatibility risk. This leads to misleading performance >>> comparisons, in much the same way as firing the "load" event before >>> images are loaded would. >>> >>>> Here is a summary of the minimum timeout for existing browsers (you >>>> can test your browser with this page: >>>> http://www.belshe.com/test/timers.html >>>> ) >>>> Safari for the mac: 10ms >>>> Safari for windows: 15.6ms >>>> Firefox: 10ms or 15.6ms, depending on whether or >>>> not Flash is running on the system >>>> IE : 15.6ms >>>> Chrome: 1ms (future - remove the clamp?) >>>> >>>> So here are a couple of options: >>>> 1) Remove or lower the clamp so that javascript apps can run >>>> substantially faster. >>>> 2) Keep the clamp and let them run slowly :-) >>>> >>>> Thoughts? It would be great to see Safari and Chrome use the same >>>> clamping values. >>> >>> Or there is option 3: >>> >>> 3) Restore the clamp for setTimeout and setInterval to 10ms for >>> compatibility, and add a new setHighResTimer API that does not have >>> any lower bound. >>> >>> This would let aware Web applications get the same benefit, but >>> without any of the compatibility risk to legacy Web content. The >>> main argument against doing things this way is that it would add API >>> surface area. But that seems like a small price to pay for removing >>> the compatibility risk, and turning the change into something other >>> browsers would be willing to adopt. >>> >>> I would like to propose an API along these lines for HTML5 but I >>> would prefer if we can achieve consensus in the WebKit community >>> first. >>> >>> Regards, >>> Maciej >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev