Using setImmediate() over setTimeout(func,0) in IE

As per IE docs setImmediate was introduced to address the core performance problem without negatively impacting power consumption. How can IE achieve this? (Specially if the reason for 4ms clamping of setTimeout was because ‘trying to increase the number of callbacks per second’ led to high power consumption)

My questions are:

  • Thinking in node if Java background
  • Is React's setState asynchronous or something?
  • Node.js: How to serialize a large object with circular references
  • async.js each get index in iterator
  • Trigger callback after getting multiple json files asynchronously
  • Firebase Callbacks - what's the underlying trigger?
    1. Doesn’t setImmediate() have all the drawbacks of setTimeout(func,0) before clamping of 4ms was introduced?
    2. Why should anyone use setImmediate() instead of setTimeout(func,0) at all then?

  • Javascript cannot unhide element after cloning?
  • synchronous vs asynchronous sequences in RxJS
  • Async waterfall equivalent with Q
  • Best practices for implementing asynchronous javascript programming with promise Q library
  • Run async code before entire mocha test
  • jQuery.noConflict() while loading jQuery asynchronously
  • One Solution collect form web for “Using setImmediate() over setTimeout(func,0) in IE”

    I’m not an expert, but here are my thoughts on this:

    setTimeout(func, 0) is basically a hack for ‘when this function returns and the UI thread is next free, run this function’. This is distinctly different from its intended usage ‘run this code after 2 seconds’. In the former, we don’t really care when the function runs – it could run in 10ms, 20ms, and if the UI thread is really busy, it could run after 3 seconds.

    Because setTimeout and setInterval is time dependent, browsers use native OS timer APIs to most efficiently achieve that. Timer APIs have a resolution, which determines how precise it can run a function at a request time. Standard windows API provides a resolution of around 15ms, which means every 15ms the CPU needs to wake up and check if there are timer callbacks that need to be executed. There are also high resolution timer APIs, and if you use those, the CPU will wake up more often to check if any callbacks are needed, and hence consume more CPU power.

    In the case of setTimeout(func, 0), the browser will schedule it to run using timer APIs and it will run when the next time the OS timers wake and check for callbacks, which if using standard timer APIs, could be from 0 to 15ms, depending on how long ago was the last iteration. This is all unnecessary as we don’t care about time anyway. We should run it independently of any timer, hence the setImmediate API. And of course, if you keep calling setImmediate, it’s gonna drive up power consumption, but when you’re not using it won’t, unlike using high resolution timers.

    So to answer your questions:

    1) I don’t think the timers are necessarily clamped to 4ms so to speak. They never had a resolution higher than 4ms. And yes, it using setImmediate a lot will drive up power consumption. As mentioned above, I think the power savings comes from when you are idling.

    2) For reasons above!!