A colleague made a long job responsive by calling setTimeout(next, 0) after every single item. Each item takes microseconds, yet the job now processes only a few hundred items per second. What is going on, and how would you fix it?

## The arithmetic Start with the numbers, because they make the diagnosis obvious. One item costs, say, 5 microseconds. One `setTimeout(next, 0)` hop costs at least the host's clamped minimum. In browsers, the HTML standard has each nested timer increment a nesting level, and once that level passes five, a requested delay below 4 ms is raised to 4 ms. A self-rescheduling chain is nested by construction, so from the sixth hop onward every hop costs about 4 ms. In Node, `setTimeout` with a delay below 1 ms is treated as 1 ms, so the same chain runs at roughly 1000 hops per second at best. One item per hop therefore gives about 250 items per second in a browser, or under 1000 in Node. The work is 0.1% of the elapsed time; the scheduling is the rest. Two hundred thousand items would take over ten minutes. ## Why the clamp exists It is a deliberate protection against exactly this pattern. Without a floor, a chained zero-delay timer is a busy loop with extra steps: it monopolises the thread while pretending to yield, and it drains battery on idle pages. Hosts impose the minimum so that a badly written chain degrades into something slow rather than something that starves everything else. It is worth being precise that this is host behaviour, not language behaviour — ECMAScript defines no timers at all. The clamp is in the HTML standard for browsers and in Node's own timer implementation. ## The fix: decouple yield frequency from work granularity The misconception behind per-item scheduling is that yielding more often means more responsive. It does not, past a point. Responsiveness is determined by the **longest** uninterrupted batch, not by the number of batches. A 5 ms batch keeps the thread available often enough for anything interactive; going finer than that buys nothing perceivable and pays a millisecond-scale toll every time. ```js function run(items, work, done) { let i = 0; (function step() { const start = Date.now(); while (i < items.length && Date.now() - start < 5) { work(items[i]); i++; } if (i < items.length) setTimeout(step, 0); else done(); })(); } ``` With 5 microsecond items, one 5 ms batch covers roughly a thousand items, so 200,000 items need about 200 hops — under a second of scheduling overhead instead of ten minutes. ## Why a time budget beats a fixed batch size A fixed count like "1000 items per batch" fixes the throughput problem but reintroduces the responsiveness problem on slow hardware or expensive rows: if items turn out to cost 200 microseconds, that batch blocks for 200 ms. Measuring elapsed time bounds what you actually care about — the blocking window — and lets the item count float. A subtlety worth mentioning: check the clock every iteration only if the check is cheap relative to the work. For extremely cheap items, `Date.now()` per iteration can itself dominate; check every N iterations instead. ```js while (i < items.length) { work(items[i]); i++; if ((i & 255) === 0 && Date.now() - start >= 5) break; } ``` ## How you would actually diagnose this in production The signature is a job whose elapsed time is a near-perfect multiple of the item count and completely insensitive to how expensive the items are. Make the work per item ten times cheaper and the job takes exactly as long — that alone identifies scheduling, not computation, as the bottleneck. Confirm it by instrumenting: log the wall time of a batch versus the gap between batches. If the gap dwarfs the batch, the yield is the cost. A second, sneakier symptom: the job runs at a *different* speed in Node than in a browser tab, and slower again in a background tab, because the clamping and throttling policies differ per host and per visibility state. Computation does not vary that way. ## What the fix does not solve Batching restores throughput and keeps responsiveness, but the work is still on the same thread, so the job still competes with everything else and still adds latency to whatever the user does while it runs. If the total is genuinely large, the honest answer may be that the algorithm should change — do less work, do it incrementally as data arrives, or precompute — rather than schedule the same work more cleverly.