<p>25のパフォーマンスがあります</p>

リグレッションについては申し訳ありませんが

申し訳ありませんが、コードベースを共有できません

絶対に何もできないという意味です。 これは、パフォーマンスの低下について聞いた最初のことです。他のすべての場所で、パフォーマンスが24から25に10〜40％_改善_していると聞いています。何らかの再現を提供する必要があります。そうしないと、この問題を解決する必要があります。現状ではまったく実行可能ではないためです。

これが修正されているのを見たい場合は、複製ケースを組み立てるのに時間を費やす必要があります。または、他の誰かがそうすることを期待します。

わかりました。おそらく最も遅い10個のテストをプルできるかどうかを確認し、24対25で実行してみます。それまでの間、CIでテストを実行する前にキャッシュをクリアすることに関して、何をお勧めしますか？ やれ？ しませんか？

構成、特にtransformsとセットアップファイルもおそらく関連性があります

CIでテストを実行する前にキャッシュをクリアすることに関して何をお勧めしますか

個人的には、偽陰性または偽陽性を与えることで陳腐化したものがないことを確認するのは良い考えだと思います。 キャッシュをクリアしないことは、テストの実行時間に大きな違いをもたらしますか？

キャッシュをクリアした後に実行すると、かなり遅くなるようです。 ヒントをありがとう私はそれを調べて、再現を試みることができるかどうかを確認します

FWIW、私はまた、v25がわずかに遅いか、v24と同等であることに気づきました。 10〜40％近くの改善は見られませんでした。

ここに記載されているように、jest 24よりも大幅に高速化されています： https ：

上記はosxでテストされました。

ただし、CentOSを実行するCIでは、まったく同じセットアップの実行速度が大幅に低下します。

Linux固有の問題？ キャッシュファイルを書き込むときのI / O関連の問題？ これを除外するためにキャッシュ生成を完全にオフにすることは可能ですか？

私たちの場合、犯人を見つけたと思います。それは--collectCoverageフラグです。 Jest 24と25の両方で削除すると、25未満のテストは約2倍の速度で実行されます。有効にすると、25未満のテストは24未満の同じテストのほぼ4倍の速度になります。

これはOSXとCentOSの両方で再現可能であるため、以前のコメントとは異なり、この問題はLinux固有ではないようです。

面白い！ イスタンブールをv3に更新しました。おそらく、そこにある何かが後退しています。 v8コードカバレッジのサポートを追加したので、そうするときにリファクタリングも台無しにした可能性があります

はい！ それは私が見ているものとも一致しています。 2倍遅いCIでカバレッジを実行しています。 そして、私がcovgなしでローカルに実行するとき、非常に高速です。 @SimenB古いイスタンブールを使用するための設定オプションはありますか？ :)

とにかくビルドする前にキャッシュを削除するので、それが実際に原因である場合は、CIでのキャッシュ生成をオフにするとよいと@csvanが言ったことをエコーし​​ます

これを再現することはできません-私がテストしたリポジトリは、v24とv25の間で--coverageとほぼ同じパフォーマンスを示します。 誰かがjest24とjest25を使ってリポジトリをまとめることができるでしょうか？それらを切り替えると違いがわかりますか？

カバレッジを無効にしてCIビルドを実行しただけですが、 @ csvanは何かに

ビルドエージェントからの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 

同様の問題が発生しています。 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構文のサポートは変更されましたか？

JSトレースはありますか？ それがどこで死んだかを見るのは興味深いでしょう。

また、Jest 25は、その構成で明示的に無効にしたファイルからカバレッジを収集するように見えるため、collectCoverageFromの処理方法が異なることに気付きました。 そこでglob構文のサポートは変更されましたか？

Micromatch 4にアップグレードしましたが、何かが変わった可能性があります。 ただし、意図的に変更することはありません。 複製で別の問題を開くことができますか？

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にアップグレードしましたが、何かが変わった可能性があります。 ただし、意図的に変更することはありません。 複製で別の問題を開くことができますか？

しましょう。

再びチャイムを鳴らします。 カバレッジは間違いなく遅く、偽物のようです。 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 v25サーカスとは何ですか？

それはより速いはずの新しいランナーを冗談で言います、しかしそれは私が見たものから決してありません。 https://www.npmjs.com/package/jest-circus

JSDOMからのjest-environment-jsdom@24をインストールして使用してみてください。 11から15にアップグレードしたので、そこにある何かが変更された可能性があります。 ロングショットのように見えますが、誰が知っていますか

@SimenBローリングはバックだけでjest-environment-jsdomに<24.0.0私の中にpackage.json間違いなく影響を与えました。 heap out of memoryエラーはなくなり、Jestは問題なく実行を完了したようです。

面白い！ 時間があれば、テストできたら素敵です

• https://www.npmjs.com/package/jest-environment-jsdom-twelve
• https://www.npmjs.com/package/jest-environment-jsdom-thirteen
• https://www.npmjs.com/package/jest-environment-jsdom-fourteen

または、 jsdomリンクして二等分します。 明日やりますが、まだいい再現がありません

次のテストでは、カバレッジを有効にしていません。

• [email protected]
  
  
  
  • テストを実行するための143秒
  
  
  • 問題ありません
  
  
• [email protected]
  
  
  
  • テストを実行するための154秒
  
  
  • 問題ありません
  
  
• [email protected]
  
  
  
  • テストを実行するための228秒
  
  
  • 🚨多くのJavaScript heap out of memoryエラー
  
  

スタックトレース

これらは、 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 

お役に立てれば

これが役立つかどうかはわかりませんが、私の組織では、Jest24からJest25（18分から28分）への大幅な速度低下があり、カバレッジ収集をオフにした後（10分まで）なくなりました。

@rosasynstylae好奇心から、あなたのコードにはたくさんのスナップショットテストがありますか？

@benmonroそうですね。

私たちもそうです！ @SimenBリポジトリ内のスナップショットがたくさんあると、これが発生する可能性があると思いますか？

スナップショットがない場合にパフォーマンスの問題が発生します。 ただし、カバレッジを収集しています。 24-> 25からの大幅な減速。2つの異なるプロジェクト。 それは変化しますが、減速は重要で一貫しています。

変更を加えずに何度もテストを実行でき、テストは平均して24倍の速度で10倍遅くなります。

24に戻すと、実行は以前の速度に戻ります。

必要に応じて、より多くの情報を提供できます。 スナップショットテストのない2つのプロジェクトについて言及したかったのです。

ここにあるすべてのコメントから、カバレッジが問題であり、おそらくイスタンブールでの回帰であるように思われますか？

ここにあるすべてのコメントから、カバレッジが問題であり、おそらくイスタンブールでの回帰であるように思われますか？

イスタンブールに指を向けるのはそれほど速くはないでしょう。 私の場合、カバレッジが無効になっている場合でも、Jest 25でパフォーマンスと安定性に重大な問題が発生しています。https： //github.com/facebook/jest/issues/9457#issuecomment-579423330を参照して

2つの別々の問題がある可能性があります。

1）jest-environment-jsdom-fourteenの問題、および
2）イスタンブールカバレッジの問題

私は格下げmicromatchに^3.0.0使用して大規模な高速化とのこぎり--coverage多かれ少なかれバック我々は冗談24缶誰の再生の下で見たパフォーマンスには、？

更新：ただし、 --coverageなしで実行すると、Jest 24レベルのパフォーマンスに戻ります-2倍遅い：-/

@EvHausチェックしてくれてありがとう、とても面白い！ 残念ながら、私はまだこれを再現することができません。 だから、複製はまだ素晴らしいでしょう、そうすれば私はこれをデバッグしようとすることができます。

私は格下げmicromatchに^3.0.0使用して大規模な高速化とのこぎり--coverage多かれ少なかれバック我々は冗談24缶誰の再生の下で見たパフォーマンスには、？

更新：ただし、 --coverageなしで実行すると、Jest 24レベルのパフォーマンスに戻ります-2倍遅い：-/

世界で何が...イスタンブールで何も見えない限り、マイクロマッチに依存しているので、それがカバレッジに影響を与える理由は私を超えています🙁

マイクロマッチ全体のパフォーマンスは少しばかげています。カバレッジv3はv4よりも高速ですが、v4がない場合はv3よりも高速ですか。 😅

@SimenBうん、確認のためにCIにも実行しました。 追加以外は何も変更しません

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

私たちのpackage.jsonは、 --coverageを使用すると、実行から6分で確実に短縮され、Jest24で見たものにほぼ戻りました。

私が見る限り、イスタンブールではマイクロマッチに依存しています

これに関連している可能性のある別のスレッドでこのコメントが見つかりました：

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

istanbulでmicromatchをプルするものがないことを確認しました（彼らはbabelプラグインでminimatchを使用します）。

確かに、除外が適切に機能していないことについての何かかもしれません。 これを使用して、インストルメントする必要があるものを確認します： https ： trueでどこでもmicromatch@4我々がないことmicromatch@3 ？

確かに2つの別々の問題のように感じます。1つはjsdomに関するもので、もう1つはカバレッジに関するものです。

micromatch @ 3も解決すると、CIで通常の速度に戻っていることを確認できます。

Jest + typescript + reactコードベースはこちら。 この問題を確認し、npm-force-resolutionsを使用してmicromatch ^ 3.0.0を強制すると、クレイジーな速度低下が修正されたようです。

構成にカスタムテストファイルパターンまたはカバレッジパターンがありますか？

@EvHaus jsdomバージョンとの大きな違いを見たように、Micromatchもダウングレードすることで違いが見られるかどうか、私は非常に興味があります

これがあなたの言いたいことなら、そうです。

  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ええ、その通りです。 否定されたパターンのマイクロマッチ回帰に関連しているようです。 ありがとう！

否定されたパターンのマイクロマッチ回帰に関連しているようです。 ありがとう！

注意して、私はそれをできるだけ早く調べます。

マイクロマッチのパフォーマンス全体が少しばかげています

パフォーマンスの低下について申し訳ありません。 グロブの正規表現を生成することは、見た目よりもはるかに困難です。 特に、否定を処理し、クロスプラットフォームにする必要がある場合。 私は今これを調べています。

@jonschlinkertそれは

はい！ @SimenBが言ったこと。 ❤️に他なりません

@EvHaus jsdomバージョンとの大きな違いを見たように、Micromatchもダウングレードすることで違いが見られるかどうか、私は非常に興味があります

私のpackage.json私は設定しました：

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

npm install再実行してから、手動でnode_modules/jest/micromatch削除しました（バージョン4でした）。 次に、テストを再実行しました。

残念ながら、まだ多くの「JavaScriptヒープのメモリ不足」エラーが発生しています。

ダウングレードは正しく行っていますか？

resolutionsはyarn resolutionsが必要ですが、 npmはまだ実装されていません（v7のロードマップにあります：https：//blog.npmjs.org/post/186983646370/npm- cli-roadmap-summer-2019）

@EvHaus npm v7がhttps ： //www.npmjs.com/package/npm-force-resolutions

遅れて申し訳ありません。 npm-force-resolutions （これは正しいことをしています）を使用してmicromatchをv3にロックしました。 残念ながら、ヒープエラーは解消されませんでした。

だから私にとっては、ここで述べられているように、それはまだ[email protected]せいです： https ：

jsdomをthirteen解決すると、それが修正されます。

25でパフォーマンスの低下を経験した人は、 jsdom @ 13またはmicromatch @ 3を使用しても修正されない問題を抱えていhttps：// github.com/micromatch/micromatch/issues/179。

JSDOMの修正バージョンがリリースされました。 jest-environment-jsdom-sixteenインストールすることで使用できます。 @EvHausで問題が

@SimenB私の問題はおそらく関連していませんが、デフォルトを使用する場合と比べてjest-environment-jsdom-sixteenを試したところ、同じテストスイートの実行時間が20秒増加しました。

v15（デフォルトでjestに付属しているもの）を使いすぎて、他の変更はありませんか？ 16.1.0でもテストできますか（ただし、メモリリークが発生するため、テストが難しい場合があります）。 JSDOMはカスタム要素のサポートを利用して着陸したばかりですが、そこに何らかのリグレッションがある可能性がありますか？ わからない

JSDOMの修正バージョンがリリースされました。jest-environment-jsdom-sixteenをインストールすることで使用できます。 @EvHausで問題が

残念ながら、まだjest-environment-jsdom-sixteenヒープエラーが発生します。 私にとってJSDomの最後の安定した動作バージョンはjest-environment-jsdom-thirteenです。

JSDOMの修正バージョンがリリースされました。 jest-environment-jsdom-sixteenインストールすることで使用できます。 @EvHausで問題が

環境はコードベースで動作しますが、実行時にほぼ100％のリグレッションが発生しています。 ちなみに、 jest-environment-jsdom-sixteenは、 25.1と24.9を使用した場合にのみ、実行時のパフォーマンスを10％向上させるようです。

こんにちは@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 |

私たちの場合、jest v25.1はv24.9と比較して約50％遅くなりましたが、最新のjest v25.2.0はv25.1と比較してさらに20％遅くなっています🙈

@olebedevうわー、それは痛いです😬

私はあなたに似た番号を取得しています。 実際のプロジェクトに基づいている場合は、v8カバレッジを使用することをお勧めします。 あなたの複製では、私のマシンでは600秒から35秒のランタイムが必要です。 大きな違いの理由は、おそらく、カバーされていないファイルをv8カバレッジでインストルメント化しようとしないことです（v8で機能するすべてのバイトがカバーされていないと言うだけです）。

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

なぜそんなに遅いのかわからない...私はそれを調べる時間を見つけようとします（しかしすぐにはありません）。 少なくともv25ではv24よりも遅くならないようにする必要があります

v8カバレッジを一緒に使用できることをドキュメントを正しく理解していますか
...-sixteen環境で？

乾杯、
J

2020年4月8日水曜日、22：33 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
。

はい、 jest-environment-jsdom-sixteen 、またはバンドルされたjest-environment-nodeです。 また、ノード8ではなく、ノード10以降でのみサポートされていることにも注意してください。

（これはNode envでのみテストしたことがありますが、バグであるjsdom envで動作しない場合は、別の問題を開いてください🙂）

jest-environment-jsdom-sixteen + v8は、カバレッジプロバイダーとして、jest 25.3.0、ノード12.16で約20％悪化しました。 また、テストパフォーマンスがjest 24から25に約80％悪化した理由をデバッグしようとしています。

@joualマイクロマッチの回避策（3.xへのダウングレード）を試しましたか？

ここでも同様の経験があり、テスト時間（カバレッジなし）はv25で35〜40秒から80〜90秒、場合によってはそれ以上に2倍になります。 v3でマイクロマッチをロックしてみましたが、測定可能な違いはありません。 Fwiw、約3kのテストがあり、そのうち58はスナップショットテストです。
jsdomをダウングレードしようとしましたが、これは私たちが使用している最近の機能のために多くのテストの破損をもたらすようです。 どうにかしてこれを回避して報告できるかどうかを確認します。

@SimenBよりきれいなプロジェクトのカバレッジ収集ジョブも非常に遅いです、あなたはそれをチェックできますか？ https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latestはカバレッジを収集しますが、他のジョブは収集しません。

ここでも同様の経験があり、テスト時間（カバレッジなし）はv25で35〜40秒から80〜90秒、場合によってはそれ以上に2倍になります。 v3でマイクロマッチをロックしてみましたが、測定可能な違いはありません。 Fwiw、約3kのテストがあり、そのうち58はスナップショットテストです。
jsdomをダウングレードしようとしましたが、これは私たちが使用している最近の機能のために多くのテストの破損をもたらすようです。 どうにかしてこれを回避して報告できるかどうかを確認します。

今日、 jest @ 24 （デフォルトではv11）でさまざまなjsdomバージョンを試していました。 v14まではすべてが正常に機能しているように見えますが、v15の時点では、テストの実行に一貫して50〜60％長くかかります。 v16でも同じ話。 jsdomをv14にダウングレードすることで、 jest @ 25で同様のパフォーマンスを取得できるかどうかを確認します。

[email protected]にはいくつかのメモリ修正がありますが、 @ EvHausで試してみてください。 Jest自身の--detect-leaksは以前のバージョンでリークを検出しましたが、16.2.2では検出しませんでした。

シンボリックリンクがたくさんある場合（Windowsでは非常に遅い）、他にもいくつかの改善点があります。したがって、人々が[email protected]を試して素晴らしいことです🙂

@SimenBそれをテストする最も簡単な方法は何ですか？ [email protected]をdevDependencyとして直接追加すると、Jestはそれを無視し、今日15.2.1であるjest-environment-jsdomバンドルされているものをすべて使用します。

npmをだまして、必要なjsdomバージョンを使用していることを確認するにはどうすればよいですか？

jest-environment-jsdom-sixteenをインストールし、それを使用しますhttps://jestjs.io/docs/en/configuration#testenvironment -string

Alphaが公開されているので、 jest@next試すことができます-すぐに使えるjsdom16が付属しています

@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]>,...

ひどい😞それはカバレッジの有無にかかわらずですか？

それは報道なしでした。 明確にすべきだった。

かなり古いバージョンのNode（v10）を実行していることが、これに影響すると思いますか？

新しいバージョンを試してみることができますが、それ以外に興味深いデータポイントはありません。 他に試すべきことは、ヒープダンプが死ぬ直前に作成することです。 ヒープには何がありますか？

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を実行すると、リークエラーが発生します。 新鮮なレポを試してみましたが、すべてうまくいきました。

https://github.com/facebook/jest/pull/10131が統合されました!! <3

26.1.0にリリースされ、人々に役立つかどうかを聞くことに非常に興味があります

@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分以上かかります。 再現のために問題を特定することはできませんが、何をテストするかについてアドバイスをいただければ、非常に興味があります。 あなたがそれに費やしたすべての仕事に感謝します！

@SimenB

prettierプロジェクトの場合、カバレッジを収集するときにv24よりも低速です。

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

バージョン25および26のパフォーマンスがBitbucketPipelineで24よりも低いことを確認できます。 また、カバレッジを有効にすると速度が低下することにも気づきました。 バージョン25は26に比べてさらに悪化し、メモリの消費によりパイプラインがクラッシュします。

@SimenB git bisectを実行して、24.9と25.1の間のパフォーマンスの低下がどこで発生したかを調べました。 24.9から26.1まで変更なしで実行されるため、よりきれいなテストを使用しました。

jsサブセットの3回の実行の累積実行時間を（しばらくの間安全にするために）無効にしたキャッシュと比較しました。 より具体的には、私が使用するコマンドは、ノード10.19の（ yarn run jest --no-cache tests/js/ ）

結果：

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のランタイムに戻ります。 それが解決策ではないと確信していますが、少なくとも私たちには何か取り組むべきことがあります。

別のデータポイントとして、私たちのjestスイートは現在[email protected]で約2767秒かかり、アップデートMRでは約3497秒かかり、約27％増加します。

素晴らしい仕事をしてくれてありがとう、jestチーム、 @ wurstbonbonの探偵スキルが、そのリグレッションの修正に役立つことを願っています！

@wurstbonbon掘るのに時間をcompileFunctionが遅いのは非常に興味深いことです...つまり、パッチを適用する代わりに、カスタムテスト環境を使用できるということです。

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

（そしてjsdom envについても同じです）。 確認できますか？

しかし、そのようなボトルネックであることは奇妙に聞こえます-18か月前にノード自体がそれを使用するように切り替えました： https ： https://github.com/nodejs/node/issues/26229は非常に興味深いものですが、おそらく私たちの側でもう少しキャッシュを行う必要がありますか？

@SimenB私はそのカスタム

ただし、jest 26でテストしているため、 MyNodeEnv.prototype.getVmContext = null;を実行する必要がありました。現在、 if (typeof this._environment.getVmContext === 'function') {チェックしているようです。 ただし、これが他の問題を引き起こす可能性があるかどうかはわかりません。

これらは、数回実行した後に表示される結果です。

Jest 26 w / testEnvironment： "ノード" => 〜280s
Jest 26 w /カスタムテスト環境=> 〜210s
ジェスト24 => 〜160秒

他の情報や何か他のことを手伝ってくれるかどうか教えてください！

予想通り、カスタム環境はよりきれいなものと同じスピードアップをもたらします。

また、コードベースで試してみましたが、違いは約270秒と約200秒であるため、約25％であり、40％の削減ではありません。 残念ながら、私たちはjest 24でテストを実行できません。これは、新しい最新のタイマーのモックに依存しているためです。

上記の例で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.',
       );

私はこれでうまくいくかもしれないと思った。

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がはるかに高速です。

@SimenBからの推奨をhttps ： //gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs？commit_id = 6d633c88caf70f712fa0ccaac42d952976161ec6

パフォーマンスは少し向上しましたが、それでもjest24.xよりもかなり低速です。

• Jest 24.x：jestテストの合計実行時間2580秒
• Jest 26.x：jestテストの合計実行時間は3166秒

@leipert jsdom環境を14にダウングレードしてみたことがありますか？

jest構成のyarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" 。 これは、私たちの期間の増加の大部分（40〜50％を追加）の原因であるように見えますが、複数の回帰が発生しているように見え始めています。

@pleunv jest24.xではjest-environment-jsdom-sixteen jsdom 16を使用していますが、Webコンポーネントのテストに関するいくつかの問題のためにアップグレードする必要がありました。 したがって、私たちが行う唯一の変更は、jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdomであるため、jsdomのバージョンも変更されません。

@wurstbonbonによって発見された問題について、 https：//github.com/nodejs/node/issues/35375アップストリームを開きました

@SimenBは、マイクロマッチの実行可能な代替案を知っていますか？ そのレポは半年以上沈黙しており、 https：//github.com/micromatch/micromatch/issues/179のようなJestに影響を与える主要な問題はまだ開いています。

実際には、それはほとんどの図書館が使用しているものです。 たとえばミニマッチを見ることができますが、それが実行可能になるとは思えません

@SimenBマイクロマッチがすべての選択肢よりも優れている

私が開いた問題のフィードバックに基づいて、ノードで修正するには少し作業が必要になると思われるため、今のところScript使用に戻す必要があると考えています。

@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) {

テストスイートでScriptを使用するようにパッチをテストしました。これが、私が得た結果です。
時間はmin:sec

名前| スイート1 | スイート2 | スイート3 | スイート4
-| -| -| -| -
ジェスト24 | 3:25 | 3:30 | 3:29 | 0:53
パッチを当てたjest26 | 3:32 | 4:36 | 3:48 | 0:53
jest26パッチなし| 5:10 | 6:12 | 5:11 | 1:07
26パッチvs24 | 4％| 31％| 9％| 1％
26パッチなしvs24 | 52％| 76％| 49％| 27％
26パッチ適用済みvsパッチなし| 46％| 35％| 36％| 25％

v26がv24でまだ改善されていないことはまだ興味深いです...

ありがとう@Cellule！ それで十分です。時間があればPRをまとめます。

すごいもの！ その場合、Micromatchの問題のみが残り、レポジトリが再びアクティブなメンテナンスを受けることを願っています。

ところで、私が推測する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)

確かに、これは私がとどまらなければならない非常に曖昧で不安定なパフォーマンスレポートですが、すべての入力が役立つと思います:)

https://github.com/facebook/jest/releases/tag/v26.5.0では、ここで説明されているvm.Script変更があります

（編集：追加の実行後に更新）

同じテストスイートでの予備的な結果：

ジェスト26.5
寒さ：59.992
ホット：43.976

ジェスト26.4：
寒さ：90.213
ホット：47.408

コールドラン<3での非常に大幅なスピードアップ

そして、これが私のテストスイートでの結果です：

ジェスト26.5
寒い：149秒

ジェスト26.4
寒い：226秒

素晴らしいニュース🙂マイクロマッチ回帰に戻ったと思います。

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％節約できます

私たちの結果：

v26.5です

• 323.98s
• 321.24秒

v24.9です

• 262.17秒
• 275.96秒

ありがとう@SimenB！ これは素晴らしいです。 〜2000スイートでの〜22000テストの結果：

• ジェスト24.x：2864秒
• ジェスト26.5.2：2967秒

これは、以前に見た約27％の速度低下と比較して、約3％遅く、したがって誤差の範囲内です。 ありがとうございます。マージする必要があります： //gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Jest 26.5.2とノード14（以前はノード10にありました）にアップグレードした後、以前に発生していた

更新：気にしないでください。 再びOOMエラーが発生し始めました。 それは私のラップトップが処理できるものの境界線上にあり、最初の数回の実行は良かったと思いますが、今は再び死にかけています。 まだ24.xxに固執する必要があります:(

誰かが興味を持っているなら、私はJSDOMと比較して非常に優れたパフォーマンスを持つDOMを作成しました。 Jestをサポートしています。

| 操作| JSDOM | Happy 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よさそうだ。 仕様に準拠していますか？

@ capricorn86よさそうだ。 仕様に準拠していますか？

ありがとう@milesj！

実装された機能は仕様に従って実装されていますが、どの仕様がカバーされているかについての詳細な概要はまだありません。 それを追加することを考えています。 ただし、すべての機能は単体テストでカバーされています。

DOMの最初の目標は、他のいくつかのプロジェクトで必要だったように、Webコンポーネントのサーバー側を優れたパフォーマンスでレンダリングできるようにすることでした。

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は著しく遅いようです。

react-scripts@4は、デフォルトでjest-circusを使用します（fwiw）。 また、 minimatchではなく、 micromatchを使用します。 ＃10131を介してmicromatchロールバックを中断したようですが、それがリグレッションの原因であるかどうかをテストするのは簡単ではありません。

@SimenB ：奇妙な移行セットアップatmがあります-これは、 CRAを使用してビルドするよう

atmの前にワークボックスがないので、実際にmicromatch意味したのか、それとも間違ったパッケージ名に焦点を合わせたのかを思い出せません:)確認する必要があります来週またそれで。

私はちょうどv26がmacOSのデフォルト端末よりもiTermで_かなり_遅いことに気づきました。 6500のテストのセットで、私は一貫して次の結果を取得します。

• v24、ターミナル：〜90年代
• v24、iTerm2：〜90s
• v26、ターミナル：〜110秒
• v26、iTerm2：〜150秒

これは、減速を解決するためにさまざまなことを何ヶ月も試みた後、少し頭を悩ませました。 Macでパフォーマンスの問題を抱えている他の誰かがこれを試すことができる可能性はありますか？ 念のために言っておきますが、これは

@pleunvこれは関連している可能性があると思います： https ：

ユーレカ。 「iTerm」を検索すると、このPRにたどり着きました。 私は以前にこれらの下線に気づきましたが、それらがハイパーリンクであることに気づいていませんでした。 そのPRを見た後、iTermでハイパーリンクを無効にして、ランタイムを130秒に短縮しました。 PRからコードを適用し、ハイパーリンクを削除した後、120秒に戻りました。 正気がわずかに回復しました。

PRが元に戻される可能性はありますか？

編集： @thymikeeは私をそれに打ち負かしました😄

@pleunv今週、それを取り戻すための時間を見つけようと思います。 実際の取引はiTermでこれを修正することですが、Linuxなどの他の端末ではハイパーリンクに問題がないためです。 iTermプロジェクトに問題を提出していただけませんか？

この変更を行ったところ、1つのテストファイルに対して1が得られました。 そして、あなたはまだURLをクリックすることができます、それはもはや下線が引かれていません。

これは、大規模な実行では巨大になる可能性があります。 ❤️

//編集
面白いことに、それがitermであるかターミナルであるかは、以前は何の違いもありませんでした。 変更後、itermの方が速くなります。

@pleunv今週、それを取り戻すための時間を見つけようと思います。 実際の取引はiTermでこれを修正することですが、Linuxなどの他の端末ではハイパーリンクに問題がないためです。 iTermプロジェクトに問題を提出していただけませんか？

ここで問題を作成しました（GitLabにあります）。 誰かが追加の詳細や再現プロジェクトを持っている場合は、遠慮なく追加してください。

その間にもう少し実験を行っていたところ、テストの小さなサブセット（数十のテストファイル）でのみ実行した場合、ハイパーリンクは一般にそれほど大きな違いをもたらさないことがわかりました。 フルセット（700ファイル）で実行すると、影響は非常に測定可能です。

また、長期的には、jestのコンソール出力が非常にグリッチ/派手になり始めるという印象もあります。 たとえば、下部の進行状況ラインは、表示よりも非表示になっています。