我正在尝试JavaScript 库 http://dtao.github.io/lazy.js/除其他外，它还提供了可以异步迭代的序列上的映射/归约函数。
A GitHub 上乐于助人的灵魂 https://github.com/dtao/lazy.js/issues/6建议对于 Node.js，我应该使用process.nextTick尽可能快地进行异步迭代。 （图书馆目前使用setTimeout在所有环境中，我确实知道这是次优的。）我对 Node 缺乏经验，所以我正在阅读此方法的工作原理，但我不清楚它是否是一个好的选择。
根据SO的另一个问题的答案 https://stackoverflow.com/questions/15349733/setimmediate-vs-nexttick，看起来使用可能更有意义setImmediate在这种情况下作为nextTick显然是跳跃ahead待处理的 I/O 事件，这对我来说似乎很糟糕。
这似乎得到了一些评论的证实Node v0.10.0 官方公告 http://blog.nodejs.org/2013/03/11/node-v0-10-0-stable/:
在 v0.10 中，nextTick处理程序在每次 C++ 调用后立即运行
到 JavaScript 中。这意味着，如果您的 JavaScript 代码调用process.nextTick，那么回调将在代码运行后立即触发
完成，但是before回到事件循环。
所以我是对的，异步迭代序列应该用setImmediate？或者会nextTick这里是更好的选择吗？ （无论哪种情况，都需要有明确的解释why将不胜感激。）
一些注意事项：
我首先要对 setImmediate 比 setImmediate 慢的程度进行严格的基准测试process.nextTick。如果它不是（慢得多）慢，我会去setImmediate立即执行，因为这不会导致事件循环枯竭。
在节点 0.10 中有一个硬限制（1000，请参阅Node.js 文档 http://nodejs.org/api/process.html#process_process_maxtickdepth）到您可以递归调用 nextTick 的次数，因此您应该在任何情况下防止这种情况发生。您要么需要在迭代之前选择策略，要么能够在迭代期间更改策略（同时检查当前迭代计数）。
如果您出于性能原因选择 process.nextTick，您可能需要为其执行的次数设置一个可配置的硬限制process.nextTick连续，然后切换到setImmediate。我没有在 Nodejs 上处理严重工作负载的经验，但我确实认为如果你的库让他们的 I/O 不稳定，人们不会喜欢它。
总而言之，setImmediate 肯定是最安全的。
至于浏览器：
我没有研究过你的图书馆，但因为你实际上来自setTimeout，您可能会通过以下方式了解新型延迟技术window.postMessage以及什么不是。有一个漂亮而小的图书馆叫做下一个报价 https://github.com/timoxley/next-tick（但与节点下一个刻度具有不同的语义！）并且有一个setImmediate 的跨浏览器填充程序 https://github.com/NobleJS/setImmediate，它相当重，因为 1) 它需要实现 setImmediate 规范（包括取消计划任务的能力），2) 它具有更广泛的浏览器兼容性。
看看这个异步排序演示 http://jphpsf.github.io/setImmediate-shim-demo/将 setImmediate (shim) 与 setTimeout 进行比较。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
