- From: James Robinson <jamesr@google.com>
- Date: Fri, 1 Jul 2011 15:54:04 -0700
- To: Jason Weber <jweber@microsoft.com>
- Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>, Jatinder Mann <jmann@microsoft.com>
- Message-ID: <CAD73md+Zp8J2bbdgTqPnK7FYW9A8ZHAEttz_6-H16g6sPKumUA@mail.gmail.com>
On Fri, Jul 1, 2011 at 3:27 PM, Jason Weber <jweber@microsoft.com> wrote: > ** ** > > *Of course, we can't get all authors to write ideal javascript code. > After all, we only had to add a clamp to setTimeout() and setInterval() > because people were creating tight loops with timeouts and using 100% of > available CPU (see https://bugzilla.mozilla.org/show_bug.cgi?id=123273, > for example). This new proposal provides another way for bad authors to > recreate the problems that lead to the clamp being necessary for > setTimeout()/setInterval() but it doesn't seem to allow any new use cases > that a good author could achieve today.* > > ** ** > > ** ** > > I agree that in an ideal world we wouldn’t need to clamp setTimeout(0) to > 4ms and could use that address this pattern rather than needing to add a new > API. Between 1990 and 2009 setTimeout was implicitly clamped (by either the > browser or the operating system) to at least 10ms on Mac OS X and Windows. > When a developer wrote, debugged, and tested code on their machine using > setTimeout(0) they would receive at most 100 callbacks a second. **** > > ** ** > > This lead to a lot of incorrect assumptions. For example, on Windows > setTimeout(0) would result in 64 callbacks a second which is ~60fps. That > meant they could successfully use setTimeout(0) for script based animations > which is of course a bug in the script but worked because of the underlying > clamps. The previous clamps helped developers write a lot of buggy code that > essentially ran at the refresh rate. > **** > > ** ** > > It’s challenging to change the implicit rules around a core API like > setTimeout after 20 years with so much buggy code out there. That’s > essentially what we’re doing by reducing the clamps to 4ms. If the legacy > throttles hadn’t existed I doubt that we would need to clamp to > setTimeout(0) which would make this discussion moot.**** > > ** ** > > We don’t believe that setImmediate should be clamped. Use agents need to > remain responsive and prioritize work accordingly. We shouldn’t allow DOS > scenarios and should be responsible citizens on the operating system. > However, if a developer would like to use the entire core of a machine for > computation on the UI thread and that webpage is in the foreground (implying > user engagement) that should be allowed.**** > > ** > What makes you think that the authors who wrote buggy code with setTimeout(0) loops will not write the same buggy code with setImmediate(), thus forcing user agents to re-introduce a clamp? - James
Received on Friday, 1 July 2011 22:54:39 UTC