Re: [ScriptYielding] setImmediate clamping returns.

> I find myself realistic unfortunately. Apparently, I am not the only one thinking that. Unfortunately too.

Without a healthy balance between "realism" and "optimism" the platform can't move forward. It seems that whenever we get into these debates on various lists, browser developers tend to retreat back to extreme pessimism and fend off any and all attempts to inject optimism or balance (or even, blame-the-developer-for-bad-code sensibility) into the equation.



> The content of the callback is irrelevant to this discussion.

I think it's entirely relevant, which is why I keep bringing it up.

If we are talking purely about the literal `(function f(){ setTimeout(f,0); })()` where there is nothing else but just a spinning callback that keeps calling itself over and over, and there's no other "contents" at all, then this is an absurd niche case.

The JS engine should be smart enough to see that there's nothing else in the function except calling itself, and just remove that code altogether, or at the very least, extremely throttle only that timer loop. *I* would say all of these should just be optimized out and have no operational effect in the browser at all:

1. function f() { setTimeout(f,0); }
2. function f() { setImmediate(f); }
3. function f() { requestAnimationFrame(f); }

Does that answer your question?

--------

OTOH, "realism" says that there's always more contents in these tight loop callbacks besides the self-reschedule.

I'm also operating under the assumption that the mechanics of actually doing the rescheduling of the loop, and the calling of the callback, all of that is relatively constant and somewhat the same "cost" in all browsers. If that's not true, and say Chrome has a much easier time of scheduling timers than FF, that's a detail I'm unaware of, and why I was asking before if there really is a reason why these tight timer loops would inequitably disfavor some specific browser.

If the timer self-rescheduling is a moot performance cost across all browsers, what else could cause one browser to suffer more harm than another with the same code, EXCEPT for the other contents of the callbacks?

And if there *are* other contents of the callbacks, and timing is different, then the focus should be on those contents, not the timers.

--------

Now, to your other scenario, that some code in a "high profile site" might have equally bad performance in all browsers, but that the bug will only be filed against FF, and that this alone will be sufficient to put enough pressure on FF to act "badly", well, I just think that's poor governance/management.

If every browser performs roughly the same, it would only be the "politics" (which you eschewed) that could put more pressure on FF than the other browsers. 



> But what sort of evil can browsers do? drop frames? They already do that. They actually happen to drop less even if rAF is misused than if it's not used at all. Please describe how browsers could do unspeakable evils to rAF, because I don't see it.

If some rAF callback schedulings get dropped altogether, not just delayed by a few animation frames worth of time, and so code I asked to run just mysteriously was ignored, that would be potentially pretty "evil". Especially if I was "abusing" rAF and doing other tasks (like remotely beaconing user actions or something) in that loop besides visual updates.

But, I really don't think it's fruitful to postulate on what "evils" might be conceived.

The point I was making is that rAF has some potential abuses, but just because it has potential abuses doesn't mean it was an ill-conceived feature. It has lots of good uses, and the cases where it could be abused are just part of playing that game (namely the blame sits squarely with the developer, not the browser). 

I think the potential abuses of setImmediate() spinning on itself and chewing up CPU unnecessarily, and that this somehow creates a politically-inconvenient situation that "hurts" one browser… all that seems to me well in line with the risks we've already set lots of precedent on with other APIs (namely, rAF). I don't see how setImmediate() creates some much bigger risk that justifies the amount of push-back it's getting. And to be explicit, I don't buy the history of setTimeout as that sufficient evidence.



> A bug will be filed on Firefox and the perf issue will be fixed quickly

Or Firefox will somehow be "forced" to neuter rAF in some evil way because fixing the other performance issues is too complicated or will take too long and they can't take the "risk" of loss of browser share. I hope we don't see that day.




--Kyle

Received on Tuesday, 13 August 2013 03:17:04 UTC