W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2011

Re: [Efficient Script Yielding] - Clamping

From: James Robinson <jamesr@google.com>
Date: Fri, 1 Jul 2011 15:54:04 -0700
Message-ID: <CAD73md+Zp8J2bbdgTqPnK7FYW9A8ZHAEttz_6-H16g6sPKumUA@mail.gmail.com>
To: Jason Weber <jweber@microsoft.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>, Jatinder Mann <jmann@microsoft.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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC