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 unresponsive.
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 <[email protected]> wrote: > Le 08/08/2013 22:04, Jason Orendorff a écrit : > > On Thu, Aug 8, 2013 at 9:40 AM, David Bruant <[email protected]> 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] https://mail.mozilla.org/**pipermail/es-discuss/2013-** > August/032630.html<https://mail.mozilla.org/pipermail/es-discuss/2013-August/032630.html> > > ______________________________**_________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
