Javascript node.js中setInterval（）的奇怪行为（仅限windows，在linux中可用）

我在使用windows机器的node.js时遇到了一些奇怪的问题，这在linux机器上是不会发生的

在低延迟设置（<100ms）下使用setInterval（）函数时：本质上，调用提供的函数的频率比我预期的要低，而且方式非常一致。当使用下面我快速编写的示例代码时，windows机器似乎给出了与linux机器一致的不同结果，即使是在相同的硬件上运行

//应该是两次执行之间的时间（毫秒）
无功延迟=10；
//运行测试需要多少秒
var测试周期=10；
var计数器=0；
var startTime=new Date（）.getTime（）；
var interval=setInterval（（）=>{
++计数器；
如果（新日期（）.getTime（）>=startTime+1000*testPeriods）{
log（'Mean Function Calls per Second:'，counter/testPeriods）；
间隔时间；
}
}，延误）；

一些测试数据，来自双引导linux和windows的我的pc：

Delay（ms）|预期| Linux结果| Windows结果
-----------+----------+--------------+---------------
100 |       10 |         10.0 |            9.2
50 |       20 |         20.0 |           16.0
25 |       40 |         39.8 |           32.0
10 |      100 |         98.4 |           63.8

您会注意到，在较低的延迟设置之前，linux的结果几乎完全匹配，即使如此，距离也不远。另一方面，windows的结果远远不够

我认为与linux版本相比，node的windows版本很可能没有得到很好的优化。因此，首先，我假设我提供的函数执行时间太长，从而延迟了下一次执行。然而，情况似乎并非如此。毕竟，如果我假设所提供的函数在任何情况下都需要相似的时间来执行，那么我知道windows机器可以在最低延迟设置下每秒执行63次。那么，为什么它应该执行约40次（延迟为25ms）却只执行约32次呢

如果有人能告诉我为什么会这样，或者我做错了什么，我将不胜感激

---

编辑：根据@jfriend00的建议简化代码，并更新测试结果以匹配。

调用一段预定代码的速度取决于操作系统的计时器中断间隔。根据操作系统的不同，此设置被称为勾选或快速勾选。在某些操作系统上，它是可配置的

操作系统会定期运行自己的代码来进行检查，比如让进程轮流使用CPU、清理内存等。为此，操作系统会设置一个计时器中断（实际上，这类似于

setInterval

仅在硬件级别）来运行自己的代码

实际上，这就是操作系统如何运行比可用内核更多的进程/线程，也是这种机制在操作系统级别驱动javascript中的

setInterval

和

setTimeout

。因此，基本上线程和

setInterval

都使用相同的操作系统机制，唯一的区别是线程可以同时使用多个内核，而

setInterval

只能使用与主js线程相同的内核

设置勾选的频率是一个权衡。将勾选设置得非常短将使操作系统更加实时，因为事件处理中的延迟大大减少。然而，这也意味着您的操作系统代码使用了更高百分比的CPU时间，留给您的应用程序的时间更少。将勾号设置得越长，应用程序的CPU时间就越长，吞吐量也就越大

我对你的结果有点惊讶。几年前（21世纪初），Linux上的默认jiffy设置相当长，因为Linux针对服务器使用进行了更多优化，因此针对吞吐量进行了优化。另一方面，由于Windows在玩游戏和运行图形应用程序等实时任务方面进行了更多优化，因此Windows的勾号较短。也许这些年来情况发生了变化

因此，是的，如果您想要跨平台一致性，则有一个跨操作系统工作的最小

setInterval

时间。然而，我猜想10毫秒就足够了，因为这是我多年来的经验（1毫秒显然会显示各种操作系统的不同行为）。如果现在10毫秒不起作用，您可以尝试更长的时间间隔，例如50毫秒或100毫秒

‡注：50毫秒或20帧/秒是无线电控制发射机的更新间隔，因此它足够实时，人类反应可以驾驶飞机、直升机和无人机而不会坠毁

---

你为什么要拍快照？为什么不检查一下总的运行时间，然后用计数器计算总的运行时间呢？仅供参考，当我简化并去掉快照时，我仍然会得到类似的结果，但代码要简单得多。@jfriend00啊，是的，那会更简单。我想我这样做是因为这个测试代码直接基于我在项目中使用的实际代码，它需要这样的结构。嗨！非常感谢你的回答。你的回答让我想到了问题的真正根源，因此我在我常用的浏览器（chrome）上而不是节点上尝试了同样的测试。在linux和windows上，我得到的结果相当于甚至优于linux平台节点的结果。这是否表明问题实际上在于windows平台节点实现本身，而不是操作系统？我知道node是基于ChromeJS引擎的一个版本，但我不确定它们有多大区别。可以是。可能会有各种各样的问题导致你的结果。首先，节点总是落后于它使用的V8版本。Chrome倾向于使用相当新的版本。所以V8中的优化在Chome上总是比在node上更好。第二