K. Gadd kg at
Thu Aug 8 14:08:29 PDT 2013

Why is the slow script dialog box even relevant for setImmediate? As I
understand it, setImmediate is equivalent to DoEvents in Visual
Basic/Windows Forms and pumping the message loop in a normal C application.
That is, you can use setImmediate to make your application run as fast as
possible while still allowing the browser to pump messages, which ensures
keyboard/mouse inputs are processed and the window does not get flagged as

This is *ideal* (especially compared to setTimeout 0, which introduces the
use of timers and slows everything down in this use case, and compared to
requestAnimationFrame which needlessly would slave computation to vsync).
People who are writing long computation loops right now that hang the
browser main thread for multiple seconds can split them up with
setImmediate without causing any major performance regressions.

Whether or not setImmediate would increase battery usage is something you'd
have to test; this isn't a case where timers would be waking the CPU up and
keeping it awake, though; this is a case where *computation* would be
keeping the CPU awake, and ultimately computation has to finish sooner or
later. You're not going to save power just by making computation take
longer unless you can ensure the CPU and other components remain in a
low-power state during the computation.

On Thu, Aug 8, 2013 at 1:26 PM, David Bruant <bruant.d at> wrote:

> Le 08/08/2013 22:04, Jason Orendorff a écrit :
>  On Thu, Aug 8, 2013 at 9:40 AM, David Bruant <bruant.d at> wrote:
>>> Small delays between (micro)task sounds like a local maximum it's hard to
>>> get away from unfortunately :-(
>> I think I was wrong here when it comes to microtasks.
> Microtasks bypass the event queue, so delaying them delays all the other
> messages in the queue by definition. Forcing a delay on microtasks means an
> irresponsive UI.
>  What if, instead of a slow script dialog, browsers responded to
>> microtask/setTimeout(0) abuse with gradual throttling? Well-behaved
>> applications would get immediate setTimeout(0) callbacks. Badly
>> behaved applications would run slowly.
> That's already the case with setTimeout in a way. Try:
>   setTimeout(function f(){
>       setTimeout(f, 0);
>   }, 0)
> You never get the slow script dialog. The 4ms clamping is here to make
> that code this code runs yet does not burn the CPU.
> Other than that, the browser with the shortest delay wins the battle, I
> believe. "my application runs faster in X than in Y" forcing Y to reduce
> the delay and align with X.
> Now that I think about it, maybe the proposal I made for microtasks [1]
> could work for setImmediate. setImmediate would be guaranteed to run asap
> (in a different task, not microtask) without clamping.
> The mitigation for browsers is possible via kill too-deeply-nested
> setImmediates (preferably before running one and not in the middle of one
> :-p) and telling the script if it asked to be notified.
> That's a version of setImmediate I would agree with as it would be a
> significant improvement over what we have today.
> David
> [1]**pipermail/es-discuss/2013-**
> August/032630.html<>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list