Guy*_*Guy 16 javascript node.js jestjs
虽然对每个人来说并不总是如此，但似乎大多数人（来自我交谈过的其他人的轶事）都体验到 Jest 在使用--maxWorkers=50%（或某些类似设置）时比未设置或将其设置为 100% 时运行得更快。
我对 8 核机器的个人经验是，如果我不设置--maxWorkers，那么我将有 7 个并发工作线程运行（正如预期的 coreCount - 1），并且它的运行速度会比我设置--maxWorkers=50%创建 4 个并发工作线程慢。
为什么会发生这种情况对我来说没有意义。即分配更多资源会减慢速度而不是加快速度。谁能解释一下吗？
Fcm*_*am5 17
正如您可能在文档中读到的--maxWorkers，单运行模式（而不是监视模式）默认设置为您机器上可用的核心，或者您的 CI 运行程序的主线程减一。
在 CI 等资源有限的环境中调整此设置可能很有用，但默认值应该足以满足大多数用例。
对于具有可用可变 CPU 的环境，您可以使用基于百分比的配置： --maxWorkers=50%
在Adobe 技术博客的这篇文章中，您将看到基准测试以及他们对为什么设置--maxWorkers=50%节省了一些时间的解释。
简而言之，他们解释了 Jest 在资源方面如何贪婪，它使用所有 CPU 核心并行运行测试，这可能会导致内存使用高峰和超时，因为它必须维护一个运行测试的子进程的工作池一个成本。
本文提供了一个基准测试，该基准测试可以让我们假设此问题可能是由 Node.js 引起的
这就是为什么如果您使用机器核心的一半，或者有时使用Jest故障排除指南--runInBand中推荐的(或) 可能会减少这种情况：--maxWorkers=1
虽然 Jest 在大多数情况下在具有快速 SSD 的现代多核计算机上速度极快，但正如我们的用户发现的那样，在某些设置上它可能会很慢。
根据调查结果，缓解此问题并将速度提高高达 50% 的一种方法是按顺序运行测试。
所以我的答案是：
生成和调度多个jest-worker的成本有时可能大于我们通过并行化获得的收益。通过使用多个工作线程，您可以实例化更多对象，这些对象将从磁盘加载不同的文件。这就是为什么在小型和原子测试中，您看不到使用--maxWorkers=50%|1.
阅读更多：
小智 -1
如果你检查进程上的 CPU 使用率和内存，你会发现当你运行 jest 时，它会创建 x 个新线程（或工作线程），并且通常使用相同数量的内存，这是因为它实际上加载了这些线程之间的所有内容，在此在这种情况下，这可能对 CI 环境有害，并且也可能意味着它会在没有真正需要的情况下消耗大量内存。如果您指定较少数量的工作线程，它将跨越更少的线程（显然），并且仍然会使用与之前使用的相同数量的内存，因此它将具有更低的处理和内存消耗。
| 归档时间： |
|
| 查看次数： |
10138 次 |
| 最近记录： |