javascript - 我应该使用 process.nextTick 还是 setImmediate 进行异步迭代？

Question

我正在处理 a JavaScript library除其他外，它提供了可异步迭代的序列上的 map/reduce 函数。

一个 helpful soul on GitHub建议对于 Node.js，我应该使用 process.nextTick 尽可能快地进行异步迭代。 (该库目前在所有环境中都使用 setTimeout，我确实理解这是次优的。)我对 Node 非常缺乏经验，所以我正在阅读这种方法的工作原理，但事实并非如此我不清楚这是否是一个好的选择。

根据the answer to another question on SO ，似乎在这种情况下使用 setImmediate 可能更有意义，因为 nextTick 显然会跳过待处理的 I/O 事件 ahead，这对我来说似乎很糟糕。

the official Node v0.10.0 announcment 中的一些评论似乎证实了这一点。 :

In v0.10, nextTick handlers are run right after each call from C++ into JavaScript. That means that, if your JavaScript code calls process.nextTick, then the callback will fire as soon as the code runs to completion, but before going back to the event loop.

我是对的，异步迭代序列应该使用 setImmediate 完成吗？或者 nextTick 会是更好的选择吗？ (无论哪种情况，我们都非常感谢您对为什么做出清晰的解释。)

Answer 1

一些注意事项:

我会首先对扩展 setImmediate 比 process.nextTick 慢的地方进行严格的基准测试。如果它不是(很多)慢，我会立即使用 setImmediate ，因为这不会使事件循环饿死。

在 Node 0.10 中有一个硬性限制(1000，参见 node.js docs)，您可以递归调用 nextTick 的次数，因此在任何情况下都应该防止这种情况发生。您要么需要在迭代之前选择策略，要么能够在迭代期间更改策略(同时检查当前迭代计数)。

如果您出于性能原因选择 process.nextTick，您可能需要设置一个可配置的硬限制，它会连续执行 process.nextTick 的次数，否则切换到 立即设置。我没有在 nodejs 上进行大量工作负载的经验，但我认为如果你的库使他们的 I/O 不稳定，人们不会喜欢它。

setImmediate 肯定是最安全的，总而言之。

关于浏览器:我没有研究过您的库，但由于您实际上来自 setTimeout，因此您可能会通过 window.postMessage 帮助您了解新型延迟技术以及其他什么.有一个不错的小型库，名为 next-tick (但语义与 Node next-tick 不同!)并且有一个 cross-browser shim for setImmediate ，这有点重，因为 1)它需要实现 setImmediate 规范(包括取消计划任务的能力)和 2)它具有更广泛的浏览器兼容性。

看看这个async sorting demo将 setImmediate (shim) 与 setTimeout 进行比较。