2f:T707,# A faster async for-loop This was fun and educational blog post by Rick Viscomi on how one might write asynchronous `for..of` loops: [Breaking Up with Long Tasks or: how I learned to group loops and wield the yield](https://calendar.perfplanet.com/2024/breaking-up-with-long-tasks-or-how-i-learned-to-group-loops-and-wield-the-yield/) However, if all you care about is async iteration, there is a lot more performance to be squeezed out. Quite a bit more: on my seven year old Lenovo P51 my final approach ends up being roughly 175-200 times faster, and on my six year old OnePlus 6T Android phone the gap increases to 250 - 1000 times. It's also backwards compatible with really old browsers (basically anything that supports Promises, really). Of course this claim comes with the caveat that my microbenchmarks are probably flawed as heck, and that you should do realistic testing and benchmarking if you're interested in optimizing a timesliced for-loop yourself! I want to clarify one thing first though: this not intended as a critique on Viscomi's article! It's well-written and has good explanations for the scheduler API, which I hadn't heard about before. Without a clearly explained example to react to I wouldn't have written the code below. This is a "yes, and..." (Also, as of writing [the `Scheduler` interface is not widely supported yet](https://developer.mozilla.org/en-US/docs/Web/API/Scheduler#browser_compatibility), so any solution using it is a no-go at my work anyway. Which is a good excuse for me to explore alternative options!) I'll repost Viscomi's final version here, modified to benchmark itself with a trivial callback so we can compare it to my own code later. The callback is trivial to ensure that we are mostly benchmarking the overhead of the loop itself.30:T5da,benchmarkScheduler = { const BATCH_DURATION = 1000 / 60; // 60 FPS let timeOfLastYield = performance.now(); function shouldYield() { const now = performance.now(); if (now - timeOfLastYield > (document.hidden ? 500 : BATCH_DURATION)) { timeOfLastYield = now; return true; } return false; } const makeArr = length => { const arr = [0]; for (let i = 1; i < length; i++) arr[i] = 0; return arr; }; let length = 1 << 10; let items = makeArr(length); let i = 0; const process = _ => items[i++] = i; async function run() { for (const item of items) { if (shouldYield()) { if (document.hidden) { await new Promise(resolve => setTimeout(resolve, 1)); timeOfLastYield = performance.now(); } else { await Promise.race([ new Promise(resolve => setTimeout(resolve, 100)), new Promise(requestAnimationFrame) ]); timeOfLastYield = performance.now(); await scheduler.yield(); } } process(item); } } let time = 0; do { length = length << 1; items = makeArr(length); i = 0; const t0 = performance.now(); await run(); time = performance.now() - t0; } while (time < 200 && length < (1 << 24)); time = 0; for (let j = 0; j < 10; j++) { i = 0; const t0 = performance.now(); await run(); time += performance.now() - t0; } time /= 10; return {arr: items, time}; }31:T975,There are a couple of directions I will explore for optimization: - `for..of`, for all of its elegance, actually has a surprisingly lot of overhead compared to a simple `for (let i = 0; i < items.length; i++)` or `while(...)` loop. The reason is the usage of the [iterator protocol](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols) under the hood. Perhaps we could write an async `forEach` that abstracts away the boilerplate above while also using a faster for loop? - whenever we yield, we create multiple promises with multiple new callbacks and calls to `setTimeout`/`requestAnimationFrame`. It should be possible to reduce that overhead to just *one* promise: the one that resolves when we're done iterating. - calling `shouldYield` is cheap, but not completely free, so doing it once per iteration adds yet more overhead. We could write code that measures iterations/batch at the end of each batch to estimate an effective reduced "sampling rate". - closures are pretty cheap these days, *but* they still have the issue the JIT often can't or won't do proper escape analysis to determine whether they can inline the variables that they close over. If the JIT kicks in at all. Let's see how it compares to a re-used "static" function. As mentioned, I cannot use the scheduler API due to a lack of browser support. Sounds like we're stuck with the `setTimeout` approach and its introduction of a 4ms delay, right? Nope! Luckily, we have had workarounds for this problem for almost fifteen years. Originally they were invented as polyfills for the proposed (but now deprecated) `setImmediate` function. Credit goes to David Baron, Mathias Bynens and Glenn Maynard. You can read the details in the following links: - https://dbaron.org/log/20100309-faster-timeouts - https://gist.github.com/mathiasbynens/579895 - https://www.w3.org/Bugs/Public/show_bug.cgi?id=15007#c18 - https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate - https://github.com/YuzuJS/setImmediate (if you need a more complete polyfill this is worth looking at) We don't really need cancellation for what we're about to write, so we can create a really minimal implementation: 32:T438,So on my machine this is over ten times faster than the previous version. Is the sampling overhead really that significant? Well... for real world code probably not. Our test callback intentionally does as little work as possible, in an attempt to benchmark the total overhead. So sampling is significant relative to the other overhead when we can ignore the overhead of the callback itself. In practice however, timeslicing solutions mostly make sense for long-running loops, and this in turn is more likely to happen if every single loop iteration is relatively time-consuming. So in real-world use-cases the callback being passed in is likely to do so much more work that most other overhead is almost negligible. Still, let's keep over-engineering something faster anyway! It's not much code and will all be hidden behind a convenient function, so why not also make it work for "lightweight" loop iterations? `asyncForEachV002` sampled every 128 iterations. One strategy is making that value adjust automatically to be relative to the actual amount of work we do per batch:33:T520,function asyncForEachV003(arr, callback, batchDuration){ return new Promise(resolve => { const t0 = performance.now(); let i = 0, batches = 1, itersPerCheck = 128, t = t0, samples = 0; const loop = () => { let tnext = t, iCheck = i + itersPerCheck; const i0 = i, batchEnd = t + batchDuration; while(i < arr.length) { callback(arr[i], i, arr); if (++i > iCheck) { samples++; if ((tnext = performance.now()) > batchEnd) break; iCheck += itersPerCheck; } } if (i < arr.length) { batches++; // i - i0 is the number of iterations in this batch // by setting itersPerCheck to 1/1024th of that, we // are essentially assuming iterations/batch won't // slow down by more than 1000x on the next batch. // If the iterations/batch value remains roughly the same, // then we should hit our target batch duration with // an error margin of around 0.01% itersPerCheck = (i0 - i) > 0xFFFFFFFF ? 0x400000 : ((i0 - i) >>> 10); t = tnext; setZeroTimeout(loop); } else { const time = performance.now() - t0; resolve({ arr, time, batches, samples }); } } loop(); }); }34:T486,asyncForEachV004 = { // This is admittedly quite awkward to write, // and having this many parameters is also // an obvious code smell. So unless it shows // a major improvement we won't pursue this. function loop(t, itersPerCheck, i, batches, samples, t0, arr, callback, batchDuration, resolve) { let tnext = t, iCheck = i + itersPerCheck; const i0 = i, batchEnd = t + batchDuration; while(i < arr.length) { callback(arr[i], i, arr); if (++i > iCheck) { samples++; if ((tnext = performance.now()) > batchEnd) break; iCheck += itersPerCheck; } } if (i < arr.length) { setZeroTimeout(loop, tnext, (i0 - i) > 0xFFFFFFFF ? 0x400000 : ((i0 - i) >>> 10), i, batches + 1, samples, t0, arr, callback, batchDuration, resolve); } else { const time = performance.now() - t0; resolve({ arr, time, batches, samples }); } } return function asyncForEachV004(arr, callback, batchDuration){ const t0 = performance.now(); return new Promise(resolve => loop(t0, 128, 0, 1, 0, t0, arr, callback, batchDuration, resolve)); }; }35:T538,asyncForEachV005 = { // Almost the same as v004, but we also explicitly // assign all parameters to local constants and variables. // Yes this is getting extremely gnarly. function loop(t, itersPerCheck, i, batches, samples, t0, arr, callback, batchDuration, resolve) { // v_l = "v locally assigned" const callback_l = callback, arr_l = arr, batchEnd = t + batchDuration, itersPerCheck_l = itersPerCheck, i0 = i; let samples_l = samples, tnext = t, i_l = i, iCheck = i + itersPerCheck; while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); if (++i_l > iCheck) { samples_l++; if ((tnext = performance.now()) > batchEnd) break; iCheck += itersPerCheck } } if (i_l < arr_l.length) { setZeroTimeout(loop, tnext, (i0 - i_l) > 0xFFFFFFFF ? 0x400000 : ((i0 - i_l) >>> 10), i_l, batches + 1, samples_l, t0, arr_l, callback_l, batchDuration, resolve); } else { const time = performance.now() - t0; resolve({ arr, time, batches, samples }); } } return function asyncForEachV005(arr, callback, batchDuration){ const t0 = performance.now(); return new Promise(resolve => loop(t0, 128, 0, 1, 0, t0, arr, callback, batchDuration, resolve)); }; }36:T4c5,function asyncForEachV006(arr, callback, batchDuration){ return new Promise(resolve => { const t0 = performance.now(); // v_c = "v closed over" // v_l = "v locally assigned" let i_c = 0, batches_c = 1, itersPerCheck_c = 128, t_c = t0, samples_c = 0; const loop = () => { let tnext = t_c, i_l = i_c, i0 = i_c, iCheck = i_c + itersPerCheck_c, samples_l = samples_c; const batchEnd = t_c + batchDuration, arr_l = arr, callback_l = callback, itersPerCheck_l = itersPerCheck_c; while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); if (++i_l > iCheck) { samples_l++; if ((tnext = performance.now()) > batchEnd) break; iCheck += itersPerCheck_l; } } if (i_l < arr_l.length) { batches_c++; itersPerCheck_c = (i_l - i0) > 0xFFFFFFFF ? 0x400000 : ((i_l - i0) >>> 10); i_c = i_l; samples_c = samples_l; t_c = tnext; setZeroTimeout(loop); } else resolve({ arr, time: performance.now() - t0, batches: batches_c, samples: samples_l }); }; loop(); }); }37:T456,While the results of the last few functions fluctuate quite wildly, it looks like the closure-with-local-variables approach does put closures in the same ballpark as parameter-passing functions. Assigning to local variables is a bit ugly compared to the "pure" closure version of course, but IMO less error prone than making sure you pass the all the parameters in the right order. On top of that, it can be used with `requestAnimationFrame`, which does not let you pass parameters to it! So I would go with the closure option. Ok, so I think I have been nerd-sniped enough by now. All that is missing is handling `document.hidden`. In my tests these loops often ended up completely paused when the document was not visible, even if I tried switching to `setTimeOut` when `document.hidden` was true. Also, Visconti's version used an extra `document.hidden ? branchDuration : branchDurationHidden` check inside the while loop. This made them significantly slower in Firefox. So instead I'll add a *single* extra if-check that makes the loop run to completion if the browser tab is hidden by the end of a batch:38:T59b,function asyncForEachV007(arr, callback, batchDuration, finishOnHide = true){ return new Promise(resolve => { const t0 = performance.now(); // v_c = "v closed over" // v_l = "v locally assigned" let i_c = 0, batches_c = 1, itersPerCheck_c = 128, t_c = t0, samples_c = 0; const loop = () => { let tnext = t_c, i_l = i_c, i0 = i_c, iCheck = i_c + itersPerCheck_c, samples_l = samples_c; const batchEnd = t_c + batchDuration, arr_l = arr, callback_l = callback, itersPerCheck_l = itersPerCheck_c; if (finishOnHide && document.hidden) { while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); i_l++; } } else { while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); if (++i_l > iCheck) { samples_l++; if ((tnext = performance.now()) > batchEnd) break; iCheck += itersPerCheck_l; } } } if (i_l < arr_l.length) { ++batches_c; itersPerCheck_c = (i_l - i0) > 0xFFFFFFFF ? 0x400000 : ((i_l - i0) >>> 10); i_c = i_l; samples_c = samples_l; t_c = tnext; setZeroTimeout(loop); } else resolve({ arr, time: performance.now() - t0, batches: batches_c, samples: samples_l }); }; loop(); }); }39:T447,function asyncForEach(arr, callback, batchDuration = 16, initialIters = 128, finishOnHide = true){ return new Promise(resolve => { let i_c = 0, t_c = performance.now(), itersPerCheck_c = initialIters; const loop = () => { let tnext = t_c, i_l = i_c, i0 = i_c, iCheck = i_c + itersPerCheck_c; const batchEnd = t_c + batchDuration, arr_l = arr, callback_l = callback, itersPerCheck_l = itersPerCheck_c; while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); if (++i_l > iCheck) { if ((tnext = performance.now()) > batchEnd) break; iCheck += itersPerCheck_l; } } if (finishOnHide && document.hidden) { while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); i_l++; } } if (i_l < arr_l.length) { i_c = i_l; t_c = tnext; itersPerCheck_c = (i_l - i0) > 0xFFFFFFFF ? 0x400000 : ((i_l - i0) >>> 10); setZeroTimeout(loop); } else resolve(); }; loop(); }); }3a:T484,function asyncForEach_scheduler(arr, callback, batchDuration = 16, initialIters = 128, finishOnHide = true){ return new Promise(resolve => { let i_c = 0, t_c = performance.now(), itersPerCheck_c = initialIters; const loop = () => { let tnext = t_c, i_l = i_c, i0 = i_c, iCheck = i_c + itersPerCheck_c; const batchEnd = t_c + batchDuration, arr_l = arr, callback_l = callback, itersPerCheck_l = itersPerCheck_c; if (finishOnHide && document.hidden) { while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); i_l++; } } while(i_l < arr_l.length) { callback_l(arr_l[i_l], i_l, arr_l); if (++i_l > iCheck) { if ((tnext = performance.now()) > batchEnd) break; iCheck += itersPerCheck_l; } } if (i_l < arr_l.length) { i_c = i_l; t_c = tnext; itersPerCheck_c = (i_l - i0) > 0xFFFFFFFF ? 0x400000 : ((i_l - i0) >>> 10); // literally the only thing we changed scheduler.postTask(loop); } else resolve(); }; loop(); }); }3b:T788,benchmarks = { rerun; const targetFrameRate = 1000 / 60; const makeArr = length => { const arr = [0]; for (let i = 0; i < length; i++) arr[i] = i; return arr; }; async function benchmark(foreach) { let callback = (_, i, a) => a[i] = i; let result; let input; let length = 1 << 9; let time = 0; while (time < 200 && length < (1 << 24)) { length = length << 1; input = makeArr(length); const t0 = performance.now(); result = await foreach(input, callback, targetFrameRate); time = performance.now() - t0; } input = makeArr(length); if (result) { result = await foreach(input, callback, targetFrameRate); const keys = Object.keys(result); for (let i = 0; i < 9; i++) { const nresult = await foreach(input, callback, targetFrameRate); for (const key of keys) { if (Array.isArray(result[key])) continue; else result[key] += nresult[key]; } } for (const key of keys) { if (Array.isArray(result[key])) continue; else result[key] /= 10; } return result; } else { const runs = []; time = performance.now(); for (let i = 0; i < 10; i++){ const t0 = performance.now(); await foreach(input, callback, targetFrameRate); runs[i] = performance.now() - t0; } return {length, runs, time: (performance.now() - time) / 10, arr: input, batches: NaN, samples: NaN}; } } const fns = [asyncForEachV000, asyncForEachV001, asyncForEachV002, asyncForEachV003, asyncForEachV004, asyncForEachV005, asyncForEachV006, asyncForEachV007, asyncForEach, asyncForEach_scheduler]; const results = {}; fns.map(fn => results[fn.name] = {started: false}); for (const fn of fns) { results[fn.name].started = true; yield results; results[fn.name] = await benchmark(fn); yield results; } }3c:[] 2d:{"title":"A faster async for-loop","cells":[{"id":429,"value":"$2f","pinned":false,"hidden":false,"mode":"md"},{"id":392,"value":"$30","pinned":true,"hidden":false,"mode":"ojs"},{"id":439,"value":"Benchmark: (only visible if the browser supports the `Scheduler` API)","pinned":false,"hidden":false,"mode":"md"},{"id":435,"value":"showBenchmark(benchmarkScheduler)","pinned":false,"hidden":false,"mode":"ojs"},{"id":0,"value":"$31","pinned":false,"hidden":false,"mode":"md"},{"id":5,"value":"// Based on Glenn Maynar's solution discussed here:\n// https://www.w3.org/Bugs/Public/show_bug.cgi?id=15007#c18\nsetZeroTimeout = {\n const taskChannel = new MessageChannel(), taskQueue = [];\n\ttaskChannel.port1.onmessage = () => {\n\t\tconst [task, args] = taskQueue.shift();\n\t\ttask.apply(task, args);\n\t};\n\n // Note that one possible advantage that setZeroTimeout has\n // over requestAnimationFrame is that one can pass it\n // parameters like setTimeout. We'll make use of that later.\n const setZeroTimeout = (task, ...args) => {\n\t\ttaskQueue.push([task, args]);\n\t\ttaskChannel.port2.postMessage(null);\n\t};\n\n // Let's try to minimize the odds of `setZeroTimeout` being\n // JIT-optimized halfway through a benchmark by giving\n // it a little warm-up loop.\n const warmup = new Promise(resolve => {\n const loop = (i) => {\n if (i++ < 100000) setZeroTimeout(loop, i);\n else resolve(setZeroTimeout);\n };\n setZeroTimeout(loop, 0);\n });\n \n\treturn warmup;\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":12,"value":"We will use this as the basis for our asynchronous loops instead of `requestAnimationFrame` because we wish to pass it arguments at some point.\n\nWriting an asynchronous loop using `setTimeout` (or `setZerotimeout`, or `requestAnimationFrame`) is pretty well-trodden ground. Let's start with the most basic version:","pinned":false,"hidden":false,"mode":"md"},{"id":117,"value":"function asyncForEachV000(arr, callback){\n return new Promise(resolve => {\n const t0 = performance.now();\n let i = 0, t = t0;\n const loop = () => {\n callback(arr[i], i, arr);\n i++;\n if (i < arr.length) setZeroTimeout(loop);\n else {\n const time = performance.now() - t0;\n resolve({\n arr,\n time,\n // dummy stats for now that will matter in later versions\n batches: arr.length,\n samples: arr.length\n });\n }\n };\n loop();\n });\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":1054,"value":"Note that this has the added benefit of abstracting a lot of the boilerplate of the earlier `for..of` loop; using it in practice would be as simple as:\n\n```javascript\nresult = await asyncForEachV000(array, callback);\n```\n\nBut how does it perform?","pinned":false,"hidden":false,"mode":"md"},{"id":326,"value":"showBenchmark(benchmarks.asyncForEachV000)","pinned":false,"hidden":false,"mode":"ojs"},{"id":660,"value":"It's a lot slower than the scheduler approach above, but we're doing a `setZeroTimeout` call per iteration, so it also isn't really batching so it's not a fair comparison (technically each iteration could be considered one \"batch\" of one item). Let's implement an actual batching approach see what difference it makes.\n\nWe'll start with adding a `batchDuration` parameter that gives us a targeted maximum time per batch. For this benchmark we're going to target 60 frames per second, and `performance.now()` uses milliseconds as its unit. So the `batchDuration` value passed in is 1000 / 60, or 16.66...","pinned":false,"hidden":false,"mode":"md"},{"id":101,"value":"function asyncForEachV001(arr, callback, batchDuration){\n return new Promise(resolve => {\n const t0 = performance.now();\n let i = 0, batches = 1, t = t0;\n const loop = () => {\n let tnext = t;\n const batchEnd = t + batchDuration;\n while(i < arr.length && (tnext = performance.now()) < batchEnd) {\n callback(arr[i], i, arr);\n i++;\n }\n if (i < arr.length) {\n t = tnext;\n batches++;\n setZeroTimeout(loop);\n } else {\n const time = performance.now() - t0;\n resolve({\n arr,\n time,\n batches,\n samples: arr.length\n });\n }\n };\n loop();\n });\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":331,"value":"showBenchmark(benchmarks.asyncForEachV001)","pinned":false,"hidden":false,"mode":"ojs"},{"id":59,"value":"Much faster already! Let's keep going. Maybe those `performance.now()` calls can have an impact? Let's reduce our \"sampling rate\":","pinned":false,"hidden":false,"mode":"md"},{"id":134,"value":"function asyncForEachV002(arr, callback, batchDuration){\n return new Promise(resolve => {\n const t0 = performance.now();\n let i = 0, batches = 1, t = t0, samples = 0;\n const loop = () => {\n let tnext = t;\n const batchEnd = t + batchDuration;\n while(i < arr.length) {\n callback(arr[i], i, arr);\n // only check every 128 iterations. This is just a test,\n // we'll make all of this auto-adjust later on.\n if (!(++i&0x7f)){\n samples++;\n if ((tnext = performance.now()) > batchEnd) break;\n }\n }\n if (i < arr.length) {\n batches++;\n t = tnext;\n setZeroTimeout(loop);\n } else {\n const time = performance.now() - t0;\n resolve({\n arr,\n time,\n batches,\n samples\n });\n }\n };\n loop();\n });\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":338,"value":"showBenchmark(benchmarks.asyncForEachV002)","pinned":false,"hidden":false,"mode":"ojs"},{"id":98,"value":"$32","pinned":false,"hidden":false,"mode":"md"},{"id":146,"value":"$33","pinned":true,"hidden":false,"mode":"ojs"},{"id":209,"value":"During the first batch we will call `performance.now()` every iteration. Then we look at how many iterations that batch processed. If we sample every `(that number)/1024` iterations, our callback would have to be 1000 times slower than the previous batch before we risk missing our deadline. At the same time the number of `performance.now()` calls is still significantly lowered, which shows in the performance difference:","pinned":false,"hidden":false,"mode":"md"},{"id":350,"value":"showBenchmark(benchmarks.asyncForEachV003)","pinned":false,"hidden":false,"mode":"ojs"},{"id":508,"value":"Zoom zoom, yet another speed increase! What's next?\n\nWell, unlike a normal for-loop we have to pause and resume the loop at times. To do so, we're using a closure that captures some variables. This can prevent them from being as optimized as a \"proper\" local variable in a function, unless the JS engine does some clever escape analysis (which it rarely does in my experience). What we could do instead is pass the variable as an argument to the loop call used in the next `setZeroTimeOut`. This also has the benefit of being able to create a function once instead of a fresh closure on each `asyncForEach` call, which makes it more likely the JS engine marks it as a hot function to JIT optimize. So let's try that:","pinned":false,"hidden":false,"mode":"md"},{"id":628,"value":"$34","pinned":true,"hidden":false,"mode":"ojs"},{"id":867,"value":"showBenchmark(benchmarks.asyncForEachV004)","pinned":false,"hidden":false,"mode":"ojs"},{"id":930,"value":"On my machine and with the browsers I tested (Firefox and Chrome on a Linux laptop and an Android phone), the parameter-based implementation is significantly faster - almost twice as fast in Firefox even. This was actually a bit of a surprise to me, because when testing this with a more minimal `loop` function with fewer parameters it did not seem to have an impact.\n\nA known problem in in older browsers was that assigning to parameters ensured that these values would be assigned to stack-allocated variables. Local variables could be optimized more than that ones. Let's test if this still has an impact on performance:","pinned":false,"hidden":false,"mode":"md"},{"id":691,"value":"$35","pinned":true,"hidden":false,"mode":"ojs"},{"id":926,"value":"showBenchmark(benchmarks.asyncForEachV005)","pinned":false,"hidden":false,"mode":"ojs"},{"id":998,"value":"So across multiple runs neither version clearly comes out ahead of the other. But hold on, assigning to local variables is also an option with closures, isn't it?","pinned":false,"hidden":false,"mode":"md"},{"id":991,"value":"$36","pinned":true,"hidden":false,"mode":"ojs"},{"id":993,"value":"showBenchmark(benchmarks.asyncForEachV006)","pinned":false,"hidden":false,"mode":"ojs"},{"id":587,"value":"$37","pinned":false,"hidden":false,"mode":"md"},{"id":917,"value":"$38","pinned":true,"hidden":false,"mode":"ojs"},{"id":880,"value":"It should perform mostly the same as before as long as the tab is active, but there is an extra branch involved so let's check.","pinned":false,"hidden":false,"mode":"md"},{"id":883,"value":"showBenchmark(benchmarks.asyncForEachV007)","pinned":false,"hidden":false,"mode":"ojs"},{"id":443,"value":"When I do multiple runs this sometimes is slower, sometimes the same, and sometimes even faster than the version without. Probably not a significant impact then. Let's remove the code that kept track of stats, that's just useless overhead now:","pinned":false,"hidden":false,"mode":"md"},{"id":594,"value":"$39","pinned":true,"hidden":false,"mode":"ojs"},{"id":747,"value":"showBenchmark(benchmarks.asyncForEach)","pinned":false,"hidden":false,"mode":"ojs"},{"id":1081,"value":"**UPDATE 2 September 2025:** One thing I had not considered is using the above approach with `scheduler.postTask` instead of `setZeroTimeOut`. In other words, using the `scheduler` API but not using the `for..of` construction at the beginning of the article. How would that compare?","pinned":false,"hidden":false,"mode":"md"},{"id":1084,"value":"$3a","pinned":true,"hidden":false,"mode":"ojs"},{"id":1089,"value":"showBenchmark(benchmarks.asyncForEach_scheduler)","pinned":false,"hidden":false,"mode":"ojs"},{"id":717,"value":"So how does our final `asyncForEach` function compare to the original scheduler code? If you opened this notebook in a browser that supports the scheduler API you can do a rough comparison below, but note that all of these values are from an overly simplistic benchmark: averaging 10 runs of each function with an unrealistic callback.\n\nHaving said that, on my seven year old Lenovo P51 my approach ends up being roughly 175-200 times faster, and on my six year old OnePlus 6T Android phone the gap increases to 250 - 1000 times. Feel free to comment with your own results!","pinned":false,"hidden":false,"mode":"md"},{"id":444,"value":"- the scheduler based approach processed **${(benchmarkScheduler.arr.length/benchmarkScheduler.time).toFixed(2)} items/ms**\n- the final `asyncForEach` processed **${(benchmarks.asyncForEach.length / benchmarks.asyncForEach.time).toFixed(2)} items/ms**\n- the final `asyncForEach` is roughly **${(benchmarks.asyncForEach.length / benchmarks.asyncForEach.time / (benchmarkScheduler.arr.length/benchmarkScheduler.time)).toFixed(3)} times ${((benchmarks.asyncForEach.length / benchmarks.asyncForEach.time) > (benchmarkScheduler.arr.length/benchmarkScheduler.time)) ? \"faster\" : \"slower\"}**\n","pinned":false,"hidden":false,"mode":"md"},{"id":600,"value":"viewof rerun = htl.html``","pinned":false,"hidden":false,"mode":"ojs"},{"id":299,"value":"$3b","pinned":true,"hidden":false,"mode":"ojs"},{"id":864,"value":"showBenchmark = stats => {\n if (stats.arr) return md`Benchmark: (average of 10 runs)\n\n- it took **${stats.time} ms** to iterate over **${stats.arr.length} items**\n- this equals **${(stats.arr.length/stats.time).toFixed(2)} items/ms**\n${stats.batches ?\n`- it took **${stats.batches} ${stats.batches > 1 ? \"batches\" : \"batch\"}**\n- each batch took **${(stats.time/stats.batches).toFixed(3)} ms**\n- each batch processed roughly **${(stats.arr.length/stats.batches).toFixed()} items/batch**`\n: `- no available stats on how many batches it took`}\n`;\n else if (stats.started) return md`*Waiting for benchmark to finish...*`;\n else return md`*Waiting for benchmark to start...*`;\n}","pinned":false,"hidden":false,"mode":"ojs"}],"files":"$W3c","stdlib":"1","titling":"auto"}