<p>有 25 场演出</p>

创建于 2020-01-24  ·  119评论  ·  资料来源: facebook/jest

💥 回归报告

我们将 jest 从 24 升级到 25，看到我们的单元测试从 jenkins 中的 5 分 23 秒变成了现在的 11 多分钟。 只有少数快照测试在升级中中断，我们-u它们，但这是一个严重的回归 imo。 请帮助我了解我们如何解决这个问题。 我们清除 CI 中的缓存以确保我们始终运行最新的。

对回归是什么的清晰简洁的描述。
运行时间从 5:23 到 11:00

最后工作版本

24.8.0
工作到版本：
24.8.0
停止在版本中工作：
25.1.0

再现

抱歉不能分享我们的代码库
重现行为的步骤：

预期行为

对您期望发生的事情的清晰简洁的描述。

链接到 repl 或 repo（强烈鼓励）

请在 GitHub 上提供repl.it 演示或最小存储库。

没有复制链接的问题可能会停滞。

运行npx envinfo --preset jest

将结果粘贴到此处：

  System:
    OS: macOS Mojave 10.14.6
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
  Binaries:
    Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
    Yarn: 1.19.0 - ~/.nvm/versions/node/v10.16.0/bin/yarn
    npm: 6.13.6 - ~/.nvm/versions/node/v10.16.0/bin/npm
Regression Needs Repro
资料来源
picture benmonro
👍18

最有用的评论

@SimenB我做了一个git bisect来找出 24.9 和 25.1 之间的性能回归是在哪里引入的。 我使用了更漂亮的测试，因为它们从 24.9 到 26.1 一直运行而无需修改。

我将 js 子集的 3 次运行的累积运行时间（为了安全一段时间）与禁用缓存进行了比较。 更特别的是，我使用的命令是 ( yarn run jest --no-cache tests/js/ ) 与节点 10.19。 因为节点 10 是 24.9 的推荐版本。

结果：

24.9.0-dev 3cdbd556948b4974b2cc23178977eb159d343df8 151.84s <- Good
25.1.0-dev 5dcc48075f22d581864f381f20bc8b257d2a73cd 223.29s <- Bad
24.9.0-dev bf6109591365a2b71c7b642fa33ed06d3db6cb26 122.58s
24.9.0-dev 77c3ceedfd61ddc841e11fec7b76e540924d3e60 120.42s
24.9.0-dev 30e08e9ae7d7d78f40df757c2ec4b49357285eda 221.28s
24.9.0-dev ad5377333daf6716af3465bba39f86b7db485e2b 222.33s
24.9.0-dev 8ddadfca76eb3fb979df81033d3d0ff564c415d6 120.32s
24.9.0-dev 966f22f2a08d9ac9300b6964ab91c4e75dba4761 120.46s
24.9.0-dev b9084101189639524863e15ef7557ea6bc6704b9 119.87s
24.9.0-dev 1d8245d77d47b4198d51e55da87893d7dfe1a759 129.93s

ad5377333daf6716af3465bba39f86b7db485e2b is the first bad commit
commit ad5377333daf6716af3465bba39f86b7db485e2b
Author: Simen Bekkhus <[email protected]>
Date:   Mon Dec 2 23:20:16 2019 +0100

    feat: add support for `compileFunction` allowing us to avoid the module wrapper (#9252)

由于如果未定义compileFunction会出现回退，我从恢复性能的 ad5377333daf6716af3465bba39f86b7db485e2b 中删除了compileFunction分支。

看看 26.1，代码已经移动了一点，但compileFunction和回退仍然存在。 所以：

26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 242.99s <- with compileFunction
26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 151.61s <- without compileFunction

即删除compileFunction分支（补丁）使 26.1 回到 24.9 的运行时。 我敢肯定这不是解决方案，但至少我们有办法解决。

picture wurstbonbon 于 2020-07-19
👍32

所有119条评论

对回归感到抱歉，但是

抱歉不能分享我们的代码库

意味着我们什么都做不了。 这是我第一次听说性能下降，在其他任何地方我都听说性能从 24 到 25 有 10-40% _improvement_。你需要提供某种复制，否则我们将不得不关闭这个问题因为它根本不可行。

如果你想看到这个地址，你需要花一些时间来制作一个复制案例，或者希望其他人这样做。

SimenB picture SimenB 于 2020-01-24

好的，我会看看我是否可以拉出我们的 10 个最慢的测试，然后尝试以 24 和 25 的速度运行它们。与此同时，您对在 CI 中运行测试之前清除缓存有什么建议？ 做吗？ 不做？

benmonro picture benmonro 于 2020-01-24

您的配置，尤其是transforms和安装文件可能也相关

在 CI 中运行测试之前，您对清除缓存有什么建议

我个人认为这是一个好主意，以确保没有任何过时的东西可以提供假阴性或阳性。 _不_清除缓存是否会对测试的运行时间产生巨大影响？

SimenB picture SimenB 于 2020-01-24

清除缓存后运行时似乎要慢一些。 感谢您的提示，我会研究一下，看看我是否可以尝试重新制作

benmonro picture benmonro 于 2020-01-24

FWIW，我还注意到 v25 要么稍微慢一点，要么与 v24 相当。 没有看到任何接近 10-40% 的改进。

milesj picture milesj 于 2020-01-24
👍4

如此处所述，我看到了比 jest 24 的显着加速： https :

以上是在osx上测试的。

然而，在我们运行 CentOS 的 CI 上，完全相同的设置运行速度要慢得多。

Linux特定问题？ 写入缓存文件时的 I/O 相关问题？ 是否可以完全关闭缓存生成以排除这种情况？

csvan picture csvan 于 2020-01-24

我想我找到了我们案例的罪魁祸首，它是--collectCoverage标志。 当 Jest 24 和 25 都删除它时，我们的测试在 25 下的运行速度大约是其两倍。启用它后，我们在 25 下的测试几乎是 24 下相同测试的 4 倍。

这在 OSX 和 CentOS 上都可以重现，因此与我之前的评论相反，该问题并非特定于 Linux。

csvan picture csvan 于 2020-01-24
🎉2

有趣的！ 我们已经将伊斯坦布尔更新到 v3，也许那里的某些东西已经退步了。 我们增加了对 v8 代码覆盖率的支持，所以我在这样做时也可能搞砸了重构

SimenB picture SimenB 于 2020-01-24
👀1

是的！ 这也与我所看到的一致。 我们在 CI 的覆盖范围内运行，它的速度慢了 2 倍。 当我在没有 covg 的情况下在本地运行时，速度非常快。 @SimenB是否有任何配置选项可以使用较旧的伊斯坦布尔？ :)

benmonro picture benmonro 于 2020-01-24
👍1

回应@csvan所说的，如果这实际上是罪魁祸首，那么关闭 CI 中的缓存生成会很好，因为我们无论如何都在构建之前将其删除

benmonro picture benmonro 于 2020-01-24

我无法重现这一点 - 我测试的存储库在 v24 和 v25 之间具有与--coverage大致相同的性能。 有人可以将 jest 24 和 jest 25 放在一起存储库，其中在它们之间切换会显示不同吗？

SimenB picture SimenB 于 2020-01-24

刚刚在禁用覆盖的情况下运行了我们的 CI 构建，我认为@csvan正在做某事。 测试运行时间为 4:00（关闭覆盖率）与 11 分钟（打开覆盖率）。 我会尝试看看我是否可以在本周末的某个时候创建​​复制品。

我们来自构建代理的 exinfo：

00:03:31.992   System:
00:03:31.992     OS: Linux 3.10 CentOS Linux 7 (Core)
00:03:31.992     CPU: (8) x64 Intel Core Processor (Skylake, IBRS)
00:03:31.992   Binaries:
00:03:31.992     Node: 10.16.0 - ~/workspace/grocery-electrode/tools/nix_64/nodejs-10.16.0/bin/node
00:03:31.992     npm: 6.9.0 - ~/workspace/grocery-electrode/tools/nix_64/npm-6.9.0/node_modules/.bin/npm
00:03:31.993   npmPackages:
00:03:31.993     jest: 25.1.0 => 25.1.0
benmonro picture benmonro 于 2020-01-24

我们看到了类似的问题。 升级 Jest 25 使我们的测试在使用覆盖率时变慢（Jest 24 为 166 秒，而 Jest 25 为 381 秒）。 在运行检查时，Jest 25 显示了许多这样的错误：

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0xb9c575dbe3d 
13: 0xb9c57ab091a 
14: 0xb9c579e7d65 
15: 0xb9c579ebaf3 

<--- Last few GCs --->

[733:0x102804000]    84639 ms: Mark-sweep 1335.2 (1449.6) -> 1325.4 (1452.1) MB, 1443.2 / 0.0 ms  (average mu = 0.135, current mu = 0.076) allocation failure scavenge might not succeed
[733:0x102804000]    85872 ms: Mark-sweep 1338.3 (1452.1) -> 1327.8 (1455.1) MB, 1159.4 / 0.0 ms  (average mu = 0.101, current mu = 0.059) allocation failure scavenge might not succeed


<--- JS stacktrace --->

降级到 Jest 24 会使这些错误消失。

我还注意到 Jest 25 处理collectCoverageFrom不同，因为它似乎从我们在该配置中明确禁用的文件中收集覆盖范围。 对 glob 语法的支持在那里改变了吗？

EvHaus picture EvHaus 于 2020-01-24
👍6

有任何 JS 痕迹吗？ 看看它死在哪里会很有趣。

我还注意到 Jest 25 处理 collectCoverageFrom 的方式不同，因为它似乎从我们在该配置中明确禁用的文件中收集覆盖率。 对 glob 语法的支持在那里改变了吗？

我们升级到了 Micromatch 4，它可能已经改变了一些东西。 但是，没有故意对其进行更改。 你能用复制打开一个单独的问题吗？

SimenB picture SimenB 于 2020-01-24

有任何 JS 痕迹吗？

这是打印的：

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x521cca5be3d]
Security context: 0x0ebfa799e6e9 <JSObject>
    1: _clearMemoizedQueries [0xebf2a5aba99] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~208] [pc=0x521cd0d9a4e](this=0x0ebf5bee2aa9 <EventTargetImpl map = 0xebf7963d039>)
    2: _clearMemoizedQueries [0xebf2a5aba99] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-...

编辑：实际上，即使禁用覆盖，我也会看到堆错误。

我们升级到了 Micromatch 4，它可能已经改变了一些东西。 但是，没有故意对其进行更改。 你能用复制打开一个单独的问题吗？

会做。

EvHaus picture EvHaus 于 2020-01-24

再次插话。 覆盖肯定更慢，而且似乎是虚假的。 这是 OSX 的时间安排。

46.69
41.77
45.06

v24 coverage
78.60
75.79
80.38

v25
45.93
52.49
53.36

v25 circus
61.27
52.08

v25 coverage
310.98
227.15
153.81

CI (travis) 的时间安排。

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s
milesj picture milesj 于 2020-01-24
👍3

@milesj什么是 v25 马戏团？

benmonro picture benmonro 于 2020-01-24

这是开玩笑的新跑步者，它应该更快，但它从来不是我所见过的。 https://www.npmjs.com/package/jest-circus

milesj picture milesj 于 2020-01-24

来自 JSDOM 的@EvHaus Traces 很有趣（当然也可能完全是巧合）。 您可以尝试安装jest-environment-jsdom@24并使用它吗？ 我们从 11 升级到 15，所以里面的东西可能已经改变了。 看起来像一个远射，但谁知道

SimenB picture SimenB 于 2020-01-27

@SimenB在我的package.json中将jest-environment-jsdom回滚到<24.0.0 package.json肯定会产生影响。 heap out of memory错误消失了，Jest 似乎没有任何问题地完成了它的运行。

EvHaus picture EvHaus 于 2020-01-28

有趣的！ 如果你有时间，如果你能测试一下就好了

或者只是链接jsdom和二等分。 我明天会做，但我还没有很好的复制品

SimenB picture SimenB 于 2020-01-28

对于以下测试，我没有启用覆盖率。

堆栈跟踪

这些是jest-environment-jsdom-fourteen运行中的一些堆栈跟踪：

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x20deef6dbe3d]
Security context: 0x36ee8219e6e9 <JSObject>
    1: _modified [0x36ee35982ec1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~189] [pc=0x20deefba6433](this=0x36eef3246e99 <EventTargetImpl map = 0x36ee99264ee9>)
    2: _insert [0x36eeb41f1e41] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourte...

    0: ExitFrame [pc: 0x2aa5df5be3d]
Security context: 0x116a8d49e6e9 <JSObject>
    1: _clearMemoizedQueries [0x116a365133d1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~208] [pc=0x2aa5dfe7dae](this=0x116a8f16cd11 <EventTargetImpl map = 0x116ae7cc9b61>)
    2: _clearMemoizedQueries [0x116a365133d1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x20deef6dbe3d 
13: 0x20deefba6433 

    0: ExitFrame [pc: 0xb8909f5be3d]
Security context: 0x09e628d9e6e9 <JSObject>
    1: childrenIterator [0x9e612e1d581] [/Users/evhaus/Git/zenhub/client/node_modules/symbol-tree/lib/SymbolTree.js:~367] [pc=0xb890a41010e](this=0x09e612e3eb01 <SymbolTree map = 0x9e6a7f56c09>,parent=0x09e685ca27d1 <EventTargetImpl map = 0x9e6061f36f1>,options=0x09e67b6026f1 <undefined>)
    2: arguments adaptor frame: 1->2
    3: _detach [0x9e65c4ae341] [/U...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x2aa5df5be3d 

    0: ExitFrame [pc: 0x180d6e95be3d]
Security context: 0x02052079e6e9 <JSObject>
    1: _modified [0x205b86c1861] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~189] [pc=0x180d6ede24fa](this=0x0205c8284411 <EventTargetImpl map = 0x205c1ea9769>)
    2: _attrModified [0x205b86ba771] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fou...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0xb8909f5be3d

希望这可以帮助

EvHaus picture EvHaus 于 2020-01-28
👍1

我不知道这是否会有所帮助，但我的组织从 Jest 24 到 Jest 25（18 分钟到 28 分钟）大幅放缓，并在关闭报道收集（降至 10 分钟）后消失。

rosasynstylae picture rosasynstylae 于 2020-01-29
👍6

@rosasynstylae出于好奇，你的代码有很多快照测试吗？

benmonro picture benmonro 于 2020-01-29

@benmonro确实如此，是的。

rosasynstylae picture rosasynstylae 于 2020-01-30

我们的也一样！ @SimenB您认为回购中的大量快照会导致这种情况吗？

benmonro picture benmonro 于 2020-01-30

我们遇到了没有快照的性能问题。 不过，我们正在收集报道。 从 24 -> 25 显着放缓。2 个不同的项目。 它有所不同，但放缓是显着且一致的。

我可以一遍又一遍地运行测试，没有任何变化，测试平均慢 10 倍，然后是 24。

我切换回 24，跑步又回到了我们习惯的速度。

如果需要，我可以提供更多信息。 我想确保提及我们的 2 个没有快照测试的项目。

joelpalmer picture joelpalmer 于 2020-01-30

从这里的所有评论来看，问题肯定是覆盖率，可能是伊斯坦布尔的回归？

milesj picture milesj 于 2020-01-30

从这里的所有评论来看，问题肯定是覆盖率，可能是伊斯坦布尔的回归？

我不会那么快把矛头指向伊斯坦布尔。 就我而言，即使禁用覆盖，我在 Jest 25 中也看到了严重的性能和稳定性问题。请参阅https://github.com/facebook/jest/issues/9457#issuecomment -579423330

可能有两个不同的问题：

1) jest-environment-jsdom-14 的问题，以及
2) 伊斯坦布尔覆盖问题

EvHaus picture EvHaus 于 2020-01-30

我将micromatch降级^3.0.0并看到使用--coverage的巨大加速，或多或少回到了我们在 Jest 24 下看到的性能。有人可以复制吗？

更新：然而，现在在没有--coverage情况下运行也回到了 Jest 24 级的性能 - 慢了两倍：-/

csvan picture csvan 于 2020-01-30

@EvHaus感谢您的检查，非常有趣！ 不幸的是，我仍然无法重现这一点。 所以复制仍然很棒，这样我就可以尝试调试它。

我将micromatch降级^3.0.0并看到使用--coverage的巨大加速，或多或少回到了我们在 Jest 24 下看到的性能。有人可以复制吗？

更新：然而，现在在没有--coverage情况下运行也回到了 Jest 24 级的性能 - 慢了两倍：-/

世界上有什么......据我所知，伊斯坦布尔没有什么取决于微匹配，所以为什么它会影响覆盖率是我无法理解的 🙁

SimenB picture SimenB 于 2020-01-30
😄1

整个 micromatch 性能的事情变得有点荒谬，覆盖率 v3 比 v4 快，没有 v4 比 v3 快？ 😅

jeysal picture jeysal 于 2020-01-30

@SimenB是的，也通过我们的 CI 运行它只是为了确认。 除了添加什么都不改变

  "resolutions": {
    "micromatch": "^3.0.0"
  }

到我们的 package.json 使用--coverage ，运行时间缩短了 6 分钟，使其大致恢复到我们在 Jest 24 下看到的情况。

csvan picture csvan 于 2020-01-30

就我所见，伊斯坦布尔没有什么取决于微匹配

在另一个可能与此相关的线程中找到此评论：

https://github.com/facebook/jest/issues/9464#issuecomment -579733243

csvan picture csvan 于 2020-01-30
👍1

刚刚确认伊斯坦布尔没有引入micromatch （他们在 babel 插件中使用minimatch ）。

当然，这可能是排除无法正常工作的原因。 我们用它来检查我们应该检测什么： https : true任何地方返回micromatch@4而我们没有为micromatch@3 ？

绝对感觉像是两个独立的问题，一个关于 jsdom，一个关于覆盖率

SimenB picture SimenB 于 2020-01-30
👍4

当我们解析micromatch@3时，我可以确认它在 CI 中恢复到正常速度。

benmonro picture benmonro 于 2020-01-30
👍1

在这里开玩笑 + 打字稿 + 反应代码库。 看到这个问题并使用 npm-force-resolutions 来强制微匹配 ^3.0.0 似乎解决了疯狂的减速。

Ancient123 picture Ancient123 于 2020-01-30

您的配置中有自定义测试文件模式 pr 覆盖模式吗？

SimenB picture SimenB 于 2020-01-30

@EvHaus如果您也通过降级 Micromatch 看到差异，我非常感兴趣，因为您看到了与 jsdom 版本的巨大差异

SimenB picture SimenB 于 2020-01-30

如果这就是你的意思，那么是的。

  collectCoverage: true,
  collectCoverageFrom: [
    'src/**/*.ts',
    'src/**/*.tsx',
    'src/**/*.js',
    'src/**/*.jsx',
    '!src/themes/**',
    '!src/**/Styled*.tsx',
    '!src/**/Styled*.ts',
    '!src/**/*Actions.ts',
    '!src/mainStore.ts',
    '!src/App.tsx',
    '!src/AppView.tsx',
    '!src/AppError.tsx',
    '!src/StyledAppComponents.tsx',
    '!src/index.tsx',
    'src/utility/redux/*.ts',
    '!src/testingUtils/*',
    '!src/**/index.ts',
    '!docs/**/**',
  ],
Ancient123 picture Ancient123 于 2020-01-30
👍1

我们也有，我们的在长度/值上看起来很相似

benmonro picture benmonro 于 2020-01-30

@Ancient123是的，没错。 似乎与否定模式的 Micromatch 回归有关。 谢谢！

SimenB picture SimenB 于 2020-01-30
👍1

似乎与否定模式的 Micromatch 回归有关。 谢谢！

注意到了，我会尽快调查的。

整个微比赛的表现变得有点荒谬

对性能下降感到抱歉。 为 globbing 生成正则表达式比看起来要困难得多。 特别是当它需要处理否定和跨平台时。 我现在正在研究这个。

jonschlinkert picture jonschlinkert 于 2020-01-30
❤10 👍8

@jonschlinkert根本没有指责的意思，非常感谢您在 Micromatch 和相关库中所做的工作！ ：心：

SimenB picture SimenB 于 2020-01-30
❤10 👍9

是的！ @SimenB说什么。 只有❤️

benmonro picture benmonro 于 2020-01-30
❤6

@EvHaus如果您也通过降级 Micromatch 看到差异，我非常感兴趣，因为您看到了与 jsdom 版本的巨大差异

在我的package.json我设置了：

"resolutions": {
    "micromatch": "^3.0.0"
}

重新运行npm install ，然后手动删除node_modules/jest/micromatch （版本4）。 然后重新运行我的测试。

不幸的是，我仍然看到许多“JavaScript 堆内存不足”错误。

我是否正确进行了降级？

EvHaus picture EvHaus 于 2020-01-31

resolutions需要yarn ， npm还没有实现它（它在 v7 的路线图上：https://blog.npmjs.org/post/186983646370/npm- cli-roadmap-summer-2019)

SimenB picture SimenB 于 2020-01-31
👍1

@EvHaus直到 npm v7 出来你可以在 npm 中使用分辨率 w/这个包： https : //www.npmjs.com/package/npm-force-resolutions

benmonro picture benmonro 于 2020-01-31

抱歉耽搁了。 使用npm-force-resolutions （这是正确的做法）将micromatch锁定到 v3。 不幸的是，它并没有让我的堆错误消失。

所以对我来说，它仍然是[email protected]的罪魁祸首，正如这里提到的： https :

将 jsdom 解析为thirteen是修复它的原因。

EvHaus picture EvHaus 于 2020-02-06

有没有在 25 中遇到性能下降的人遇到使用jsdom@13或@3无法解决的问题？ 正在修复 JSDOM 中的内存泄漏（https://github.com/jsdom/jsdom/pull/2840 和从中链接的各种问题/PR），并且已经报告并正在处理 micromatch 中的回归： https:// github.com/micromatch/micromatch/issues/179。

SimenB picture SimenB 于 2020-02-16
👍3

JSDOM 的固定版本已经发布，您可以通过安装jest-environment-jsdom-sixteen来使用它。 @EvHaus你能验证它解决了你的问题吗？

SimenB picture SimenB 于 2020-02-17
❤1

@SimenB我的问题可能不相关，但我尝试了jest-environment-jsdom-sixteen与使用默认值的对比，并且看到重复运行后相同测试套件的运行时间增加了 20秒。

csvan picture csvan 于 2020-02-17

使用 v15（默认情况下是 jest 附带的）并且没有其他更改？ 您是否也可以使用 16.1.0 进行测试（尽管这会泄漏内存，因此可能更难测试）。 JSDOM 刚刚登陆自定义元素支持，其中_可能_有一些回归吗？ 不确定

SimenB picture SimenB 于 2020-02-17

JSDOM 的固定版本已经发布，你可以通过安装 jest-environment-jsdom-sixteen 来使用它。 @EvHaus你能验证它解决了你的问题吗？

不幸的是， jest-environment-jsdom-sixteen仍然出现堆错误。 JSDom 的最后一个稳定工作版本是jest-environment-jsdom-thirteen 。

EvHaus picture EvHaus 于 2020-02-18

JSDOM 的固定版本已经发布，您可以通过安装jest-environment-jsdom-sixteen来使用它。 @EvHaus你能验证它解决了你的问题吗？

该环境适用于我们的代码库，但我们仍然看到运行时几乎 100% 回归。 有趣的是， jest-environment-jsdom-sixteen似乎仅在使用25.1与24.9时才能将运行时间性能提高 10%

joscha picture joscha 于 2020-03-16

嗨@SimenB ，

我在这里做了可重现的案例https://github.com/olebedev/jest-perf-issue。 请看一下。 下面的结果进行比较。 /cc @joscha

结果

基准测试在MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz 。

| 开玩笑版| 分公司| 时间 |
|:--------------|:------:|---------:|
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

olebedev picture olebedev 于 2020-03-25
❤7 👍7

在我们的例子中，jest v25.1 比 v24.9 慢了大约 50%，现在最新的 jest v25.2.0 比 v25.1 慢了 20% 🙈

falkenhawk picture falkenhawk 于 2020-03-26

@olebedev哇，好痛苦😬

我得到的数字与你相似。 如果它基于真实项目，我建议使用 v8 覆盖率。 在您的复制中，我的机器上的运行时间从 600 秒到 35 秒。 巨大差异的原因可能是我们没有尝试使用 v8 覆盖率检测未覆盖的文件（我们只是说每个字节都未覆盖，这适用于 v8）。

https://jestjs.io/docs/en/configuration#coverageprovider -string

不知道为什么它这么慢......我会试着找一些时间来研究它（虽然不会很快）。 至少在 v25 上不应该比 v24 慢

SimenB picture SimenB 于 2020-04-08

我是否正确理解文档，我们可以一起使用 v8 覆盖
使用...-sixteen环境？

干杯，
J

2020 年 4 月 8 日星期三，Simen Bekkhus， notifications @github.com 写道：

@olebedev https://github.com/olebedev哇，好痛苦😬

我得到的数字与你相似。 如果它是基于一个真实的项目，我
推荐使用 v8 覆盖。 我的运行时间从 600 秒到 35 秒
机器在您的复制中。 巨大差异的原因可能是
我们不会尝试使用 v8 覆盖来检测未覆盖的文件。

https://jestjs.io/docs/en/configuration#coverageprovider -string

不知道为什么它这么慢......我会试着找一些时间来研究它。
至少在 v25 上不应该比 v24 慢

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 ，或
退订
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

joscha picture joscha 于 2020-04-08

是的，要么是jest-environment-jsdom-sixteen ，要么是捆绑的jest-environment-node 。 另请注意，它仅在节点 10+ 上受支持，在节点 8 上不受支持。

（我曾经只用 Node env 测试过这个，但如果它不适用于 jsdom env，那就是一个错误 - 请打开一个单独的问题🙂）

SimenB picture SimenB 于 2020-04-08

jest-environment-jsdom-sixteen + v8 作为覆盖提供者在 jest 25.3.0，节点 12.16 上对我们来说差了大约 20%。 我们还试图调试为什么我们的测试性能从 jest 24 到 25 下降了大约 80%。

joual picture joual 于 2020-04-08

@joual您是否尝试过微

csvan picture csvan 于 2020-04-08

在这里有类似的经历，v25 上的测试时间（_无_覆盖）从 35-40 秒增加到 80-90 秒，有时甚至更多。 在 v3 上尝试锁定 micromatch，没有可测量的差异。 Fwiw，我们有大约 3k 个测试，其中 58 个是快照测试。
尝试降级 jsdom，但这似乎由于我们最近使用的功能而引入了大量测试中断。 会看看我是否能以某种方式解决这个问题并报告回来。

pleunv picture pleunv 于 2020-04-10

@SimenB prettier 项目的覆盖率收集工作也很慢，你能检查一下吗？ https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest收集报道，其他工作没有。

fisker picture fisker 于 2020-04-11

在这里有类似的经历，v25 上的测试时间（_无_覆盖）从 35-40 秒增加到 80-90 秒，有时甚至更多。 在 v3 上尝试锁定 micromatch，没有可测量的差异。 Fwiw，我们有大约 3k 个测试，其中 58 个是快照测试。
尝试降级 jsdom，但这似乎由于我们最近使用的功能而引入了大量测试中断。 会看看我是否能以某种方式解决这个问题并报告回来。

今天在jest@24 （默认为 v11）上试验了不同的 jsdom 版本。 在 v14 之前，一切似乎都运行良好，但从 v15 开始，测试运行时间始终延长 50-60%。 v16 中的相同故事。 看看我是否可以通过将 jsdom 降级到 v14 在jest@25上获得类似的性能。

pleunv picture pleunv 于 2020-04-24
👍7

[email protected]有一些内存修复， @EvHaus你能试试吗？ Jest 自己的--detect-leaks在以前的版本中发现了泄漏，但不是 16.2.2。

如果您有很多符号链接（这在 Windows 上非常慢），我还进行了一些其他改进，所以如果人们可以尝试[email protected] ，那就太好了🙂

SimenB picture SimenB 于 2020-05-01

@SimenB测试它的最简单方法是什么？ 如果我直接添加[email protected]作为 devDependency Jest 会忽略它并使用与jest-environment-jsdom捆绑在一起的任何内容，即今天的 15.2.1。

我如何欺骗npm以确保它使用我想要的 jsdom 版本？

EvHaus picture EvHaus 于 2020-05-01
👍1

安装 jest-environment-jsdom-sixteen 并使用它https://jestjs.io/docs/en/configuration#testenvironment -string

SimenB picture SimenB 于 2020-05-01

Alpha 已发布，因此您可以尝试jest@next - 它带有开箱即用的 jsdom 16

SimenB picture SimenB 于 2020-05-02
👍2

@SimenB抱歉， [email protected]及其[email protected]运气不佳。 仍然收到许多这些错误：

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

最终跑步者死亡。

我的细节：

> npx envinfo --preset jest

  System:
    OS: macOS 10.15.4
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
  Binaries:
    Node: 10.17.0 - ~/.nvm/versions/node/v10.17.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v10.17.0/bin/npm
  npmPackages:
    jest: ^26.0.0-alpha.0 => 26.0.0-alpha.0

以下是其中一些返回的完整堆栈：

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x3f82f50dbe3d 
13: 0x3f82f5c630de 
14: 0x3f82f5c94431 
15: 0x3f82f5c7d3be 
16: 0x3f82f5c4e98b 
17: 0x3f82f5c3c38e 

<--- Last few GCs --->

[50818:0x102804000]   189738 ms: Mark-sweep 1288.8 (1450.6) -> 1280.2 (1454.1) MB, 890.1 / 0.1 ms  (average mu = 0.181, current mu = 0.061) allocation failure scavenge might not succeed
[50818:0x102804000]   190673 ms: Mark-sweep 1292.8 (1454.1) -> 1282.9 (1457.6) MB, 856.2 / 0.2 ms  (average mu = 0.136, current mu = 0.084) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x3f82f50dbe3d]
Security context: 0x274d67c9e6e9 <JSObject>
    1: createImpl [0x274d6d9ba1b9] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/generated/HTMLInputElement.js:~47] [pc=0x3f82f5c630de](this=0x274d51911261 <Object map = 0x274dd51fe489>,globalObject=0x274d89d38609 <Window map = 0x274d2fe6c211>,constructorArgs=0x274d832134b1 <JSArray[0]>,privateData=0x274d832134d1 <Object map = 0x274d69...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x2cea552dbe3d 
13: 0x2cea55937c04 
14: 0x2cea5592618b 

<--- Last few GCs --->

[51263:0x102804000]    34292 ms: Mark-sweep 1332.4 (1452.5) -> 1320.5 (1453.5) MB, 902.6 / 0.0 ms  (average mu = 0.149, current mu = 0.104) allocation failure scavenge might not succeed
[51263:0x102804000]    35480 ms: Mark-sweep 1332.6 (1453.5) -> 1323.6 (1457.5) MB, 1049.3 / 0.0 ms  (average mu = 0.131, current mu = 0.116) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x2cea552dbe3d]
Security context: 0x1a4cb371e6e9 <JSObject>
    1: next [0x1a4ca627dcd1] [/Users/evhaus/Git/zenhub/client/node_modules/symbol-tree/lib/TreeIterator.js:~16] [pc=0x2cea55937c04](this=0x1a4c807c75b1 <TreeIterator map = 0x1a4c38b8a9c9>)
    2: shadowIncludingInclusiveDescendantsIterator(aka shadowIncludingInclusiveDescendantsIterator) [0x1a4ca627a641] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/li...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x3e0d8aedbe3d 
13: 0x3e0d8b35eedc 

<--- Last few GCs --->

[51519:0x102804000]    28074 ms: Mark-sweep 1324.5 (1445.0) -> 1315.7 (1449.0) MB, 760.4 / 0.0 ms  (average mu = 0.182, current mu = 0.080) allocation failure scavenge might not succeed
[51519:0x102804000]    28906 ms: Mark-sweep 1328.5 (1449.0) -> 1317.7 (1452.0) MB, 770.4 / 0.0 ms  (average mu = 0.129, current mu = 0.074) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x3e0d8aedbe3d]
Security context: 0x3611d141e6e9 <JSObject>
    1: queueMutationRecord(aka queueMutationRecord) [0x361185f32321] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/helpers/mutation-observers.js:~33] [pc=0x3e0d8b35eedc](this=0x361116e826f1 <undefined>,type=0x3611aa0a3681 <String[9]: childList>,target=0x36110b275a91 <EventTargetImpl map = 0x3611a254a2f1>,name=0x361116e822b1 <null>,name...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x8d8aedbe3d 
<--- Last few GCs --->

[51526:0x102804000]    33125 ms: Mark-sweep 1318.6 (1425.0) -> 1317.7 (1424.0) MB, 874.8 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure scavenge might not succeed
[51526:0x102804000]    33136 ms: Scavenge 1318.5 (1424.0) -> 1318.0 (1424.5) MB, 3.8 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure 
[51526:0x102804000]    33148 ms: Scavenge 1318.7 (1424.5) -> 1318.2 (1425.0) MB, 4.2 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x8d8aedbe3d]
    1: StubFrame [pc: 0x8d8ae8d40b]
    2: ConstructFrame [pc: 0x8d8ae8cfa3]
Security context: 0x3324ecd9e6e9 <JSObject>
    3: new NodeImpl(aka NodeImpl) [0x3324c2083e11] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~125] [pc=0x8d8b357fd4](this=0x332437582801 <the_hole>,globalObject=0x3324b10f98e9 <Window map = 0x3324649cf0a1>,args=0x3324b1841471 <JSArray[0]>,...
EvHaus picture EvHaus 于 2020-05-02

太糟糕了😞 有没有覆盖？

SimenB picture SimenB 于 2020-05-02

那是没有覆盖的。 应该澄清一下。

您认为我运行的是相当旧版本的 Node (v10) 会是其中的因素吗？

EvHaus picture EvHaus 于 2020-05-02

您可以尝试使用较新的版本，如果不出意外，这将是一个有趣的数据点。 其他要尝试的事情是尝试在它死之前进行堆转储。 堆上有什么？

SimenB picture SimenB 于 2020-05-02

有趣的是，没有人提到micromatch@4不再缓存正则表达式（参见https://github.com/micromatch/micromatch/pull/151和https://github.com/facebook/jest/pull/10131引入缺失在开玩笑的一面缓存。

对我来说，降级到micromatch@3并升级到jest-environment-jsdom-sixteen节省了 50% 的时间。
但是对于 jest 26 和内置的 jsdom，在我的情况下使用 --detectLeaks 运行 jest 时仍然出现泄漏错误。 尝试了新的回购，一切正常。

7rulnik picture 7rulnik 于 2020-06-20

https://github.com/facebook/jest/pull/10131合并了！！ <3

csvan picture csvan 于 2020-06-23
👍5 ❤2

在 26.1.0 发布，非常有兴趣听到它是否对人们有帮助

SimenB picture SimenB 于 2020-06-23
🚀4 ❤4 🎉3

@SimenB非常感谢您的发布！ 不幸的是，在我们这边，我们仍然面临着巨大的差异：

当前的：

os: osx
node: 12.6.1
jest: 24.9
-----------------
174 test suites
823 tests
322 snapshots
-----------------
done in 23.569s

在高于 24.9 的每个版本上

os: osx
node: 12.6.1
jest: 26.1.0
-----------------
174 test suites
823 tests
322 snapshots
-----------------
done in 133.763s

使用新缓存和完全重新安装所有节点模块后。 未触及的配置。
在监视模式下运行测试在我的机器上需要超过 3 分钟才能确定要运行哪些测试。 我无法真正隔离复制问题，但如果你给我一些建议来测试什么，我会非常感兴趣。 感谢您为此付出的所有工作！

zanettin picture zanettin 于 2020-06-23
👍2

@西门子

对于prettier项目，在收集覆盖率时仍然比v24慢。

image

image

https://github.com/prettier/prettier/pull/8636

fisker picture fisker 于 2020-06-24
👍2

我可以确认版本 25 和 26 的性能在 Bitbucket Pipeline 上低于 24。 我还注意到，随着覆盖率的启用，速度会增加。 与 26 相比，版本 25 变得更糟，并且管道因内存消耗而崩溃。

tsantos84 picture tsantos84 于 2020-06-24

@SimenB我做了一个git bisect来找出 24.9 和 25.1 之间的性能回归是在哪里引入的。 我使用了更漂亮的测试，因为它们从 24.9 到 26.1 一直运行而无需修改。

我将 js 子集的 3 次运行的累积运行时间（为了安全一段时间）与禁用缓存进行了比较。 更特别的是，我使用的命令是 ( yarn run jest --no-cache tests/js/ ) 与节点 10.19。 因为节点 10 是 24.9 的推荐版本。

结果：

24.9.0-dev 3cdbd556948b4974b2cc23178977eb159d343df8 151.84s <- Good
25.1.0-dev 5dcc48075f22d581864f381f20bc8b257d2a73cd 223.29s <- Bad
24.9.0-dev bf6109591365a2b71c7b642fa33ed06d3db6cb26 122.58s
24.9.0-dev 77c3ceedfd61ddc841e11fec7b76e540924d3e60 120.42s
24.9.0-dev 30e08e9ae7d7d78f40df757c2ec4b49357285eda 221.28s
24.9.0-dev ad5377333daf6716af3465bba39f86b7db485e2b 222.33s
24.9.0-dev 8ddadfca76eb3fb979df81033d3d0ff564c415d6 120.32s
24.9.0-dev 966f22f2a08d9ac9300b6964ab91c4e75dba4761 120.46s
24.9.0-dev b9084101189639524863e15ef7557ea6bc6704b9 119.87s
24.9.0-dev 1d8245d77d47b4198d51e55da87893d7dfe1a759 129.93s

ad5377333daf6716af3465bba39f86b7db485e2b is the first bad commit
commit ad5377333daf6716af3465bba39f86b7db485e2b
Author: Simen Bekkhus <[email protected]>
Date:   Mon Dec 2 23:20:16 2019 +0100

    feat: add support for `compileFunction` allowing us to avoid the module wrapper (#9252)

由于如果未定义compileFunction会出现回退，我从恢复性能的 ad5377333daf6716af3465bba39f86b7db485e2b 中删除了compileFunction分支。

看看 26.1，代码已经移动了一点，但compileFunction和回退仍然存在。 所以：

26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 242.99s <- with compileFunction
26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 151.61s <- without compileFunction

即删除compileFunction分支（补丁）使 26.1 回到 24.9 的运行时。 我敢肯定这不是解决方案，但至少我们有办法解决。

wurstbonbon picture wurstbonbon 于 2020-07-19
👍32

作为另一个数据点，我们的 jest 套件目前使用[email protected]需要大约 2767 秒，而在我们的更新 MR 中需要大约 3497 秒，增加了大约 27%。

感谢所有出色的工作，jest 团队，我希望@wurstbonbon的侦探技巧可以帮助您解决回归问题！

leipert picture leipert 于 2020-08-13

@wurstbonbon感谢您抽出时间来挖掘！ 非常有趣的是compileFunction速度较慢......这应该意味着您可以只使用自定义测试环境而不是应用补丁。

const NodeEnv = require('jest-environment-node');

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

（对于 jsdom env 也是如此）。 你确定吗？

尽管这样的瓶颈听起来很奇怪 - Node 本身在 18 个月前开始使用它： https : https://github.com/nodejs/node/issues/26229非常有趣 - 也许我们需要做更多的缓存？

SimenB picture SimenB 于 2020-08-13

@SimenB我只是尝试了一些类似于那个自定义 env 的东西，它看起来好一点（但仍然比 jest 24 慢）。

我不得不这样做MyNodeEnv.prototype.getVmContext = null; ，不过，因为我与笑话26测试，它看起来像它检查if (typeof this._environment.getVmContext === 'function') {现在。 不过，不确定这是否会导致其他问题。

这些是我运行几次后看到的结果：

Jest 26 w/testEnvironment：“节点”=> ~280s
Jest 26 w/自定义测试环境 => ~210s
开玩笑 24 => ~160 秒

如果我可以提供任何其他信息或其他信息，请告诉我！

emilio-notable picture emilio-notable 于 2020-08-14

正如预期的那样，自定义 env 会为更漂亮的人带来相同的加速。

我也在我们的代码库上尝试过，其中的差异是 ~270s 和 ~200s，所以只有大约 25% 而不是 40% 的减少。 不幸的是，我无法使用 jest 24 运行我们的测试，因为我们依赖于新的现代计时器模拟。

wurstbonbon picture wurstbonbon 于 2020-08-15

我在上面的例子中遗漏了一个delete ，抱歉。

我想知道手动缓存编译的函数是否足够 - 你能尝试应用这个补丁吗？ （此处包含转译的 JS 和 TS 源）

diff --git i/packages/jest-runtime/build/index.js w/packages/jest-runtime/build/index.js
index 1d094a6dc0..f6d059caa3 100644
--- i/packages/jest-runtime/build/index.js
+++ w/packages/jest-runtime/build/index.js
@@ -267,6 +267,7 @@ const getModuleNameMapper = config => {
 const unmockRegExpCache = new WeakMap();
 const EVAL_RESULT_VARIABLE = 'Object.<anonymous>';
 const runtimeSupportsVmModules = typeof _vm().SyntheticModule === 'function';
+const compiledFunctionCache = new Map();
 /* eslint-disable-next-line no-redeclare */

 class Runtime {
@@ -1169,23 +1170,30 @@ class Runtime {
       value: this._createRequireImplementation(localModule, options)
     });
     const transformedCode = this.transformFile(filename, options);
-    let compiledFunction = null; // Use this if available instead of deprecated `JestEnvironment.runScript`
+    let compiledFunction = undefined; // Use this if available instead of deprecated `JestEnvironment.runScript`

     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = (0, _vm().compileFunction)(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
-              filename,
-              parsingContext: vmContext
-            }
-          );
-        } catch (e) {
-          throw (0, _transform().handlePotentialSyntaxError)(e);
+        const params = this.constructInjectedModuleParameters();
+        const cacheKey = transformedCode + params;
+        compiledFunction = compiledFunctionCache.get(cacheKey);
+
+        if (!compiledFunction) {
+          try {
+            compiledFunction = (0, _vm().compileFunction)(
+              transformedCode,
+              params,
+              {
+                filename,
+                parsingContext: vmContext
+              }
+            );
+            compiledFunctionCache.set(cacheKey, compiledFunction);
+          } catch (e) {
+            throw (0, _transform().handlePotentialSyntaxError)(e);
+          }
         }
       }
     } else {
@@ -1194,13 +1202,13 @@ class Runtime {
       const runScript = this._environment.runScript(script);

       if (runScript === null) {
-        compiledFunction = null;
+        compiledFunction = undefined;
       } else {
         compiledFunction = runScript[EVAL_RESULT_VARIABLE];
       }
     }

-    if (compiledFunction === null) {
+    if (!compiledFunction) {
       this._logFormattedReferenceError(
         'You are trying to `import` a file after the Jest environment has been torn down.'
       );
diff --git i/packages/jest-runtime/src/index.ts w/packages/jest-runtime/src/index.ts
index 522adabd1e..8958a4cef8 100644
--- i/packages/jest-runtime/src/index.ts
+++ w/packages/jest-runtime/src/index.ts
@@ -137,6 +137,8 @@ type RunScriptEvalResult = {[EVAL_RESULT_VARIABLE]: ModuleWrapper};

 const runtimeSupportsVmModules = typeof SyntheticModule === 'function';

+const compiledFunctionCache = new Map<string, ModuleWrapper>();
+
 /* eslint-disable-next-line no-redeclare */
 class Runtime {
   private _cacheFS: StringMap;
@@ -1000,24 +1002,29 @@ class Runtime {

     const transformedCode = this.transformFile(filename, options);

-    let compiledFunction: ModuleWrapper | null = null;
+    let compiledFunction: ModuleWrapper | undefined = undefined;

     // Use this if available instead of deprecated `JestEnvironment.runScript`
     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = compileFunction(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
+        const params = this.constructInjectedModuleParameters();
+
+        const cacheKey = transformedCode + params;
+
+        compiledFunction = compiledFunctionCache.get(cacheKey);
+
+        if (!compiledFunction) {
+          try {
+            compiledFunction = compileFunction(transformedCode, params, {
               filename,
               parsingContext: vmContext,
-            },
-          ) as ModuleWrapper;
-        } catch (e) {
-          throw handlePotentialSyntaxError(e);
+            }) as ModuleWrapper;
+            compiledFunctionCache.set(cacheKey, compiledFunction);
+          } catch (e) {
+            throw handlePotentialSyntaxError(e);
+          }
         }
       }
     } else {
@@ -1028,13 +1035,13 @@ class Runtime {
       );

       if (runScript === null) {
-        compiledFunction = null;
+        compiledFunction = undefined;
       } else {
         compiledFunction = runScript[EVAL_RESULT_VARIABLE];
       }
     }

-    if (compiledFunction === null) {
+    if (!compiledFunction) {
       this._logFormattedReferenceError(
         'You are trying to `import` a file after the Jest environment has been torn down.',
       );

编辑：不，这太糟糕了🙈 我在 Node 问题中问过是否可以填充编译缓存🤞

SimenB picture SimenB 于 2020-08-15
👍1

我认为这可能会奏效。

const params = this.constructInjectedModuleParameters();
const cacheKey = transformedCode + params;
const cachedData = compileFunctionCache.get(cacheKey);

try {
  compiledFunction = (0, _vm().compileFunction)(
    transformedCode,
    params,
    {
      filename,
      parsingContext: vmContext,
      cachedData,
      produceCachedData: !cachedData,
    },
  );

  if (compiledFunction.cachedDataProduced) {
    compileFunctionCache.set(cacheKey, compiledFunction.cachedData);
  } 
} catch (e) {
  throw (0, _transform().handlePotentialSyntaxError)(e);
}

它稍微提高了性能，但Script仍然要快得多。

wurstbonbon picture wurstbonbon 于 2020-08-15

尝试了@SimenB的建议： https : //gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs ? commit_id = 6d633c88caf70f712fa0ccaac42d952976161ec6

虽然它确实提高了一点性能，但它仍然比 jest 24.x 慢得多：

  • Jest 24.x：我们的 Jest 测试的总运行时间为 2580 秒
  • Jest 26.x：我们的 Jest 测试总运行时间为 3166 秒
leipert picture leipert 于 2020-08-19

@leipert您是否曾尝试将 jsdom 环境降级到 14？

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen"在你的笑话配置中。 对于我们来说，这似乎仍然是导致持续时间增加的主要原因（增加 40-50%），但看起来似乎存在多重回归。

pleunv picture pleunv 于 2020-08-21

@pleunv使用 jest 24.x 我们在 jsdom 16 上使用jest-environment-jsdom-sixteen ，由于测试 Web 组件的一些问题，我们不得不升级。 所以我们做的唯一改变是： jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom ，所以 jsdom 版本甚至没有改变。

leipert picture leipert 于 2020-08-23

在上游打开https://github.com/nodejs/node/issues/35375关于@wurstbonbon 发现的问题

SimenB picture SimenB 于 2020-09-27
👀4 ❤2 🚀1 🎉1 👍1

@SimenB你知道https://github.com/micromatch/micromatch/issues/179仍然悬而未决。

csvan picture csvan 于 2020-09-27

不是真的，这是大多数图书馆使用的。 可以看看例如 minimatch，但我怀疑它是否可行

SimenB picture SimenB 于 2020-09-27

@SimenB是什么让

kibertoad picture kibertoad 于 2020-09-27

根据我打开的问题中的反馈，我认为我们现在应该恢复使用Script ，因为它似乎需要在 Node 中进行一些工作来修复它。

@leipert @wurstbonbon或其他任何人，你能在你的node_modules/jest-runtime/build/index.js试试这个补丁吗？

diff --git i/packages/jest-runtime/build/index.js w/packages/jest-runtime/build/index.js
index 851d8e12cd..7235082546 100644
--- i/packages/jest-runtime/build/index.js
+++ w/packages/jest-runtime/build/index.js
@@ -1170,35 +1170,24 @@ class Runtime {
       value: this._createRequireImplementation(localModule, options)
     });
     const transformedCode = this.transformFile(filename, options);
-    let compiledFunction = null; // Use this if available instead of deprecated `JestEnvironment.runScript`
+    let compiledFunction = null;
+    const script = this.createScriptFromCode(transformedCode, filename);
+    let runScript = null; // Use this if available instead of deprecated `JestEnvironment.runScript`

     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = (0, _vm().compileFunction)(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
-              filename,
-              parsingContext: vmContext
-            }
-          );
-        } catch (e) {
-          throw (0, _transform().handlePotentialSyntaxError)(e);
-        }
+        runScript = script.runInContext(vmContext, {
+          filename
+        });
       }
     } else {
-      const script = this.createScriptFromCode(transformedCode, filename);
-
-      const runScript = this._environment.runScript(script);
+      runScript = this._environment.runScript(script);
+    }

-      if (runScript === null) {
-        compiledFunction = null;
-      } else {
-        compiledFunction = runScript[EVAL_RESULT_VARIABLE];
-      }
+    if (runScript !== null) {
+      compiledFunction = runScript[EVAL_RESULT_VARIABLE];
     }

     if (compiledFunction === null) {

我需要调整 v8 代码覆盖率的工作方式，但我会尝试在明天或下周打开 PR。

SimenB picture SimenB 于 2020-10-01
❤11 👀3 🚀3

我测试了补丁以在我们的测试套件上使用Script ，这是我得出的结果
时间在min:sec

姓名 | 套房 1 | 套房 2 | 套房 3 | 套房 4
-- | -- | -- | -- | ——
笑话 24 | 3:25 | 3:30 | 3:29 | 0:53
jest 26 打补丁 | 3:32 | 4:36 | 3:48 | 0:53
jest 26 未修补 | 5:10 | 6:12 | 5:11 | 1:07
26 补丁 vs 24 | 4% | 31% | 9% | 1%
26 未打补丁 vs 24 | 52% | 76% | 49% | 27%
26 修补与未修补 | 46% | 35% | 36% | 25%

迭代 | 套房 1 | 套房 2 | 套房 3 | 套房 4
-- | -- | -- | -- | ——
开玩笑 24 - 1 | 2:58 | 3:37 | 3:33 | 0:47
开玩笑 24 - 2 | 3:18 | 3:34 | 3:32 | 0:51
开玩笑 24 - 3 | 3:27 | 3:08 | 3:48 | 0:59
开玩笑 24 - 4 | 3:37 | 3:44 | 3:38 | 0:53
开玩笑 24 - 5 | 3:45 | 3:31 | 2:56 | 0:55
jest 26 打补丁 - 1 | 3:42 | 4:31 | 4:08 | 0:57
jest 26 打补丁 - 2 | 3:11 | 4:18 | 3:28 | 0:57
jest 26 打补丁 - 3 | 3:55 | 5:12 | 3:19 | 0:55
jest 26 打补丁 - 4 | 3:22 | 4:25 | 4:20 | 0:46
开玩笑 26 未打补丁 - 1 | 4:30 | 6:12 | 4:28 | 1:08
jest 26 未修补 - 2 | 5:16 | 6:17 | 5:18 | 1:05
开玩笑 26 未打补丁 - 3 | 5:46 | 6:07 | 5:49 | 1:09

所有测试都在相同的提交和类似的测试环境中运行（Azure DevOps Hosted Ubuntu 18）
我只花时间在我的测试套件上运行 jest。
我的大多数套件本质上都相似（所有后端单元测试）

据我所知，使用Script的补丁确实对性能产生了巨大的影响。
我不知道Suite 2的放缓是异常值还是真正的回归（只运行了 4 次）。
看起来确实仍然存在性能回归，但没有那么糟糕

Cellule picture Cellule 于 2020-10-02
👍9 ❤5 🚀4

仍然有趣的是 v26 仍然没有改进 v24 ......

kylemh picture kylemh 于 2020-10-03

谢谢@Cellule！ 这对我来说已经足够了 - 有时间我会整理一个 PR

SimenB picture SimenB 于 2020-10-03
❤3 👍3 🚀2

很棒的东西！ 那就只剩下 Micromatch 问题了，希望这个 repo 会再次受到积极维护。

csvan picture csvan 于 2020-10-03

顺便说一句，我假设 JSDOM 中也有性能回归。 正如我在一个大型网络项目上所做的那样的测试。 没有应用上述补丁。
它看起来像那样。

Jest 24  (testEnvironment: "jsdom") (no rewires latest CRA)
144.014s

Jest 24 (testEnvironment: "jest-environment-jsdom-sixteen") (rewire latest CRA that changes testEnvironment)
409.473s (also few failed tests)

Jest 26 (testEnvironment: "jsdom") (no rewires latest CRA) so old jsdom? Whatever is the default for Jest 26 I assume? (I used react-app-rewired to rewire jest config and pnpmfile.js to override what version of Jest was installed with `react-scripts` as it still ships Jest 24 (like resolutions in yarn))
310.275s

Jest 26 (testEnvironment: "jest-environment-jsdom-sixteen") (rewire latest CRA that changes testEnvironment + pnpmfile.js)
over 1200s+ (some tests failed plus test run just stuck forever)

当然，这是一份超级模糊和不稳定的绩效报告，我必须留下来，但我认为每个输入都有帮助:)

RIP21 picture RIP21 于 2020-10-04
👀3

https://github.com/facebook/jest/releases/tag/v26.5.0有此处讨论的vm.Script更改

SimenB picture SimenB 于 2020-10-05
❤9

（编辑：在额外运行后更新）

同一测试套件的初步结果：

开玩笑 26.5
冷：59.992
热: 43.976

玩笑 26.4：
冷：90.213
热: 47.408

冷运行时非常显着的加速 <3

csvan picture csvan 于 2020-10-05
👀1

这是我的测试套件的结果：

开玩笑 26.5
冷：149s

开玩笑 26.4
冷：226s

kkckkc picture kkckkc 于 2020-10-05
🚀3 ❤2 👀1

好消息🙂我想我们又回到了微匹配回归，然后

SimenB picture SimenB 于 2020-10-05
❤11

如果你们使用npm-force-resolutions来强制安装 micromatch 3。它可能在[email protected]不起作用

// package.json
  ...
  "preinstall": "npx npm-force-resolutions",
  ..
  "resolutions": {
    "micromatch": "^3.0.0"
  }

运行测试时出错：

TypeError: _micromatch(...).default.scan is not a function
    at globs.map.glob (/home/travis/build/removed/node_modules/jest-util/build/globsToMatcher.js:65:47)
    at Array.map (<anonymous>)
    at globsToMatcher (/home/travis/build/removed/node_modules/jest-util/build/globsToMatcher.js:61:26)
    at new SearchSource (/home/travis/build/removed/node_modules/@jest/core/build/SearchSource.js:197:49)
    at contexts.map.context (/home/travis/build/removed/node_modules/@jest/core/build/runJest.js:265:16)
    at Array.map (<anonymous>)
    at runJest (/home/travis/build/removed/node_modules/@jest/core/build/runJest.js:264:34)
    at startRun (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:479:35)
    at runWithoutWatch (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:494:10)
    at _run10000 (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:416:13)
npm ERR! Test failed.  See above for more details.

@SimenB非常感谢您的更新。 更新到[email protected]后，它在 Travis 上为我们节省了 20% 的运行时间

nvh95 picture nvh95 于 2020-10-06

我们的结果：

它是 v26.5

  • 323.98s
  • 321.24s

它是 v24.9

  • 262.17s
  • 275.96s
falkenhawk picture falkenhawk 于 2020-10-07
👍1

谢谢@SimenB！ 这真太了不起了。 我们在大约 2000 个套件中进行了大约 22000 次测试的结果：

  • Jest 24.x：2864 秒
  • 玩笑 26.5.2：2967 秒

与我们之前看到的约 27% 的放缓相比，这大约慢了 3%，因此在误差范围内。 谢谢，现在我们只需要合并： https :

leipert picture leipert 于 2020-10-07
🚀1

只是想指出，在升级到 Jest 26.5.2 和 Node 14（之前在 Node 10 上）后，我之前遇到的所有“内存堆不足”问题都消失了。 不确定有多少问题是由 Jest 和 Node 引起的，但如果其他人看到类似的问题，请尝试升级到两者。

更新：没关系。 我又开始收到 OOM 错误了。 我想它正好在我的笔记本电脑可以处理的边界上，前几次运行很好，但现在它又死了。 仍然必须坚持 24.xx :(

EvHaus picture EvHaus 于 2020-10-08
👍2

如果有人感兴趣，我已经创建了一个与 JSDOM 相比具有非常好的性能的 DOM。 它支持 Jest。

| 操作 | JSDOM | 快乐DOM |
| ------------------------------------- | ------- | --------- |
| 导入/需要 | 333 毫秒 | 45 毫秒 |
| 解析 HTML | 256 毫秒 | 26 毫秒 |
| 序列化 HTML | 65 毫秒 | 8 毫秒 |
| 渲染自定义元素 | 214 毫秒 | 19 毫秒 |
| querySelectorAll('tagname') | 4.9 毫秒 | 0.7 毫秒 |
| querySelectorAll('.class') | 6.4 毫秒 | 3.7 毫秒 |
| querySelectorAll('[属性]') | 4.0 毫秒 | 1.7 毫秒 |
| querySelectorAll('[class~="name"]') | 5.5 毫秒 | 2.9 毫秒 |
| querySelectorAll(':nth-child(2n+1)') | 10.4 毫秒 | 3.8 毫秒 |

项目链接：
https://github.com/capricorn86/happy-dom/

capricorn86 picture capricorn86 于 2020-10-13
❤2

@capricorn86看起来不错。 是否符合规范？

milesj picture milesj 于 2020-10-13

@capricorn86看起来不错。 是否符合规范？

谢谢@milesj！

已实现的功能已根据规范实现，但尚无关于涵盖哪些规范的详细概述。 我正在考虑添加。 但是，单元测试涵盖了所有功能。

DOM 的最初目标是能够以良好的性能呈现 Web 组件服务器端，因为我在其他一些项目中需要它。

capricorn86 picture capricorn86 于 2020-10-13

FWIW，我只是尝试将我们的项目从使用 Jest 24.9 的react-scripts@3提升到使用 Jest 26.6 的@react-scripts@4 。

我们的服务器 API 测试套件之前的执行时间约为 180-190 秒。 切换到 Jest 26.6 后，它始终需要大约 220 秒。 我什至尝试将minimatch分辨率强制为4.0.2 。 将测试运行程序切换到jest-circus似乎会延迟几秒钟，但总体而言，26.6 似乎明显变慢了。

markerikson picture markerikson 于 2020-10-29

react-scripts@4默认使用jest-circus ，fwiw。 它也是我们使用的micromatch ，而不是minimatch 。 似乎我们已经通过 #10131 中断了回滚micromatch ，但是，因此不再那么容易测试这是否是回归的原因

SimenB picture SimenB 于 2020-10-31

@SimenB ：我们有一个奇怪的迁移设置 atm - 这是一个遗留的 MEAN / AngularJS 应用程序，我转换为使用 CRA 构建。 测试配置完全是我们自己的，而不是内置的 CRA Jest 配置——我们只是利用了 CRA 附带 Jest 作为依赖项这一事实。

我的自动取款机前面没有我的工作箱，所以现在我不记得我的意思是micromatch还是我真的把注意力集中在了错误的包名上:) 我得看看下周再来。

markerikson picture markerikson 于 2020-10-31
👍1

我刚刚注意到 v26 在 iTerm 中的运行速度比在 macOS 的默认终端中慢很多。 在一组 6500 次测试中，我始终得到以下结果：

  • v24，终端：~90s
  • v24，iTerm2：~90s
  • v26，终端：~110s
  • v26，iTerm2：~150s

经过几个月的尝试各种方法来解决放缓问题后，这让我有点吃惊。 在 Mac 上有性能问题的其他人有机会尝试一下吗？ 请注意，这是v26上的 jsdom

pleunv picture pleunv 于 2020-11-23
👀1

@pleunv我相信这可能与此有关： https :

thymikee picture thymikee 于 2020-11-23

尤里卡。 搜索“iTerm”把我带到了这个 PR 。 我以前注意到这些下划线，并没有意识到它们是超链接。 看到那个 PR 后，我禁用了 iTerm 中的超链接，这使我的运行时间缩短到 130 秒。 应用 PR 中的代码并删除超链接后，我又回到了 120 秒。 理智稍微恢复。

PR有机会重新加入吗？

编辑： @thymikee打败了我😄

pleunv picture pleunv 于 2020-11-23

@pleunv我会在这周找一些时间把它带回来。 虽然真正的交易是为 iTerm 解决这个问题，因为其他终端，例如 Linux 上的超链接没有问题。 您介意向 iTerm 项目提出问题吗？

thymikee picture thymikee 于 2020-11-23

我刚刚做了这个更改，它给了我 1s 的单个测试文件。 你仍然可以点击网址，只是不再有下划线。
image

对于较大的运行，这可能是巨大的。 ❤️

//编辑
有趣的是，之前它是 iterm 还是终端并没有什么区别。 更改后 iterm 对我来说更快。

beckerei picture beckerei 于 2020-11-23
👍1

@pleunv我会在这周找一些时间把它带回来。 虽然真正的交易是为 iTerm 解决这个问题，因为其他终端，例如 Linux 上的超链接没有问题。 您介意向 iTerm 项目提出问题吗？

我在这里创建了一个问题（他们在 GitLab 上）。 如果有人有其他详细信息或重现项目，请随时添加。

与此同时，我进行了更多实验，我发现，当只在较小的测试子集（几十个测试文件）上运行它时，超链接通常不会产生太大的不同。 虽然在我们的全套（700 个文件）上运行它时，影响是非常可衡量的。

我也有这样的印象，从长远来看，jest 的控制台输出开始变得非常有问题/浮华。 例如，底部的进度线隐藏多于可见。

pleunv picture pleunv 于 2020-11-23
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

Secretmapper picture Secretmapper  ·  3评论
ticky picture ticky  ·  3评论
paularmstrong picture paularmstrong  ·  3评论
GrigoryPtashko picture GrigoryPtashko  ·  3评论
stephenlautier picture stephenlautier  ·  3评论