Re: [ScriptYielding] setImmediate clamping returns.

I'll take a stab at part of this.

AFAICT, setImmediate is spec'd to happen *after* the currently waiting events on the queue are exhausted, as soon as possible, which should mean that the UI remains responsive even in a tight setImmediate() loop.

I doubt the claims that `function f(){ setTimeout(f,0); }` (or something like it) *must* drain the battery and that the only solution is clamping such a loop. But that's history. I don't think we need to re-debate the past.

The current debate is: is `function f(){ setImmediate(f); }` really something that would *inequitably* discriminate against one browser and thus force that browser to clamp, and then topple all the dominoes of the other browsers.

We have to face the fact that this is more about politics than technology. If a high-profile demo shows that FF is killing battery life, FF is going to move to plug the sinking boat, regardless of if that's actually the right answer. And if it's Chrome on the losing side of some high profile demo, Chrome is likely to do the same.

BUT, why should `function f(){ setImmediate(f); }` inequitably harm one browser vs. another? I don't see any reason. Of course, if there's more stuff in the callback (there always is), THAT stuff might run faster or slower in different browsers, and THAT stuff might be to blame, but instead of blaming THAT stuff, `setImmediate()` is likely to get blamed.



--Kyle





On Aug 12, 2013, at 5:51 PM, David Bruant <bruant.d@gmail.com> wrote:

> Hi,
> 
> I've been discussing setImmediate recently in various places and been told that here would be the most appropriate place [1], so here I am :-)
> 
> I have read through the archives of this list and couldn't find all the answers to my questions/concerns.
> 
> First off, something is not entirely clear to me. I've just been pointed out by John-David Dalton [2] to a page [3] that suggests that the current HTML5 "250 callbacks per second" is a madness that drains battery:
> "Browsers have attempted to increase the number of callbacks per second that JavaScript developers can receive through the setTimeout and setInterval API’s (...) preventing hardware from entering low power states."
> This suggests that running more callbacks per second is detrimental to battery
> On the other hand, setImmediate suggests that the callback should be run as fast as possible. It's also been said on this list [4] that Microsoft doesn't think setImmediate should be clamped (because that would result in less callbacks calls per seconds).
> Which one do we want for setImmediate? More or less callbacks per seconds?
> 
> I would like to discuss the idea of clamping.
> Firefox [5] once had a case of a website doing in essence:
> (function f(){ setTimeout(f, 0); })();
> And that would make the CPU go to 100%.
> Their response was to align to what other browsers were doing which was to reinterpret "0" as something a bit higher (10ms at the time).
> 10ms was later changed to 4ms and only for deeply-nested setTimeouts (so, setTimeout(f,0) really means 0 until you've done it 4 times in a row after which there is the minimum 4ms delay).
> 
> The bug that was reported against Firefox, was found somewhere else too [6], so (function f(){ setTimeout(f, 0); })(); is something write. Not these exact characters, not intentionally, but they write it and, unclamped, that uses the CPU 100%. I would be interested to know what is expected to happen for
> (function f(){ setImmediate(f); })();
> It's been suggested [4] that clamping is not an option. And that differentiates setImmediate from setTimeout.
> Now, Adam Barth suggested [6] that if a browser implements a clamping for setImmediate, then, websites with the (function f(){ setImmediate(f); })(); mistake would eat less battery in this browser and users would be incentivized to use it instead of non-setImmediate-clamping browsers. We all know that the natural consequence is all browsers moving to the clamping behavior, having to de facto standardize that behavior and effectively making setImmediate nothing but a setTimeout 0 equivalent.
> How can this situation be avoided? (given the current setImmediate spec, I can't see how)
> 
> Thanks,
> 
> David
> 
> [1] https://twitter.com/getify/status/365800931176095746
> [2] https://twitter.com/jdalton/status/367038319151955968
> [3] http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
> [4] http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0012.html
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=123273
> [6] see [4] at the end of https://groups.google.com/a/chromium.org/d/msg/blink-dev/Hn3GxRLXmR0/XP9xcY_gBPQJ
> [7] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Hn3GxRLXmR0/P9zOB1HIQ4IJ
>

Received on Monday, 12 August 2013 23:02:59 UTC