All 15 Event Loop & Non-blocking IO questions
More in Event Loop & Non-blocking IO
What is the event loop, and why does it allow Node.js to handle many concurrent operations despite being single-threaded? What is the difference between concurrency and parallelism, and which one does Node.js's event loop actually provide by default? What is a callback queue (or task queue) in the context of the Node.js event loop, and how does it relate to the call stack? What does 'non-blocking I/O' mean, and how does a Node.js function like fs.readFile() achieve it compared to fs.readFileSync()? How does the event loop handle a large synchronous loop (like processing a huge array with a for loop), and what problem does this cause? What does it mean that Node.js's I/O is handled by libuv, and how does libuv abstract different operating systems' I/O mechanisms? What is the difference between synchronous and asynchronous versions of the same core Node.js API, using fs.readFile vs fs.readFileSync as an example, and when is the synchronous version actually appropriate? How would you measure how 'busy' the event loop is in a running Node.js process using a simple technique? What are the distinct phases of the Node.js event loop, and what kind of callbacks does each phase execute? What is 'event loop lag' (or 'event loop delay'), and how would you monitor it in a production Node.js application?
Advertisement
Back to results for “Performance Optimization & Profiling”
Node.js › Event Loop & Non-blocking IO

How does setImmediate() differ from process.nextTick() in terms of timing and typical use cases?

Intermediate

Answer

process.nextTick() schedules a callback to run at the very end of the current operation, before the event loop proceeds to any of its formal phases -- it has the highest possible priority and is typically used for ensuring some cleanup or continuation happens immediately after the current synchronous code finishes, before any I/O. setImmediate() schedules a callback for the 'check' phase, after I/O callbacks in the current loop iteration have run -- typically used to defer a piece of work until after I/O events have had a chance to be processed, avoiding starving I/O the way excessive nextTick recursion could.
function processLargeArray(items, index = 0) {
  const chunkEnd = Math.min(index + 1000, items.length);
  for (let i = index; i < chunkEnd; i++) { /* process items[i] */ }
  if (chunkEnd < items.length) {
    setImmediate(() => processLargeArray(items, chunkEnd)); // yields to I/O between chunks
  }
}
Real-world example A large-array processing function uses setImmediate() to break its work into chunks, yielding control back to the event loop between chunks specifically so pending I/O (like incoming HTTP requests) gets a chance to be handled rather than being starved by continuous synchronous processing.

Common follow-ups: Why can recursive use of process.nextTick() starve I/O entirely, while recursive setImmediate() doesn't have the same effect?;In what scenario would you deliberately choose process.nextTick() over a regular Promise microtask for similar 'run soon' semantics?

Advanced Node.js;Performance Optimization & Profiling
All 15 Event Loop & Non-blocking IO questions