Jest: Jestは、すべてのWindowsマシン（Windows 10以下）で3倍遅くなります

関連：＃6783

起動が遅いですか、それともウォッチモードですか？ 起動時にwatchmanをインストールしてみると、役立つはずです（https://facebook.github.io/watchman/docs/install.html）

テストを通過するときは、そこから先は問題ないように見えます（編集：実際には、テストを実行するときも遅くなります。標準が0.05のように感じられる間、0.5秒の速度で1つずつ通過します。
テストあたりの秒数）
ただし、jestテストの起動および/または開始には時間がかかります（約4〜6秒の遅延、Macマシンよりも4〜6倍遅い）

私は警備員を試して、あなたに戻ります

たとえばndbスタートアップを使用してプロファイルを作成し、何が遅いかを把握できれば、それも大きな助けになります🙂

ウォッチマンがインストールされていても、遅延はまだ遅いです。
「jest--verbose」を実行しているndbでプロファイリングテストを実行しました。結果は次のとおりです。

最初の1.7秒のスクリーンショット：

1.8秒から2.7秒のスクリーンショット

記録後にndbのプロファイルタブから保存された.jsonファイルと.heapsnapshotファイル：

profiling.zip

@pfftdammitchris遅いことに気付いた[正確な]ユースケースは何ですか？
（1つのファイルまたは複数のファイル）？ （ウォッチモードまたはいいえ）？ 例を提供できますか。
1つのファイルの監視モードの問題について=>最後のコメントを読んでください：＃6783

ウォッチモードの有無にかかわらず、単一ファイルと複数ファイルの両方で低速です。 テストを実行するたびに、テストの初期化に3秒以上の遅延があり、mocha / chaiなどの他のテストランナーが通常実行するのに対し、テストの実行は1つずつ0.3、0.4、または0.5秒遅くなります。それぞれ0.05秒のように感じます。

私はcodesandboxでjestを使用していますが、初期化/実行テストでjestを即座に実行しているようです。同僚が、Macマシンでjestを実行しているのを見て、通常どおりに実行しています。 私の知る限り、これは単なるWindowsマシンです。 私は職場でWindowsマシンを使用していますが、jestで問題が発生しています。また、自宅でもWindowsマシンを使用していますが、問題はここでも続きます。

--runInBandを使用しましたが、感覚に基づいて、ユニットテストがさらに0.2秒ずつ少し遅くなったようです。

明確化

--runInBandを使用しましたが、感覚に基づいて、ユニットテストがさらに0.2秒ずつ少し遅くなったようです。

=> v24で試しましたか？ v23からv24まで、このシナリオでのみ優れた改善が見られます。
_ rerunでwatch 、1つのファイルに対して実行した場合のみ（最初の実行ではない）_
-> 2/3秒が0.4 / 0.5秒に低下します。
しかし、Macと比較して私は試したことがありません...だから多分それはまだ悪いです...現在の改善があっても

@SimenB

1. 私が考えるhttps://github.com/facebook/jest/issues/7110 ALL問題のあるシナリオのためのWindows上で冗談速度回帰[V23 VS V22]として。
   ＃6783はそのうちの1つです

2.この問題は次のように考えることができます：すべての問題のあるシナリオでのjest [Mac vsWindows]の速度の問題。

こんにちは皆さん ！
私はjest24とwindows10の遅さを累積します（400回のテストで800秒！）。 これらすべてを高速化するために私が見つけたより速い方法は、powershellまたはcmdの代わりにwslを使用することです。 今、私のテストは「たった」189秒しかかかりません。

Windows 10ビルド15063マシン、16GBのCore i7で実行するのに1分43秒かかる1302テストの144個のテストファイルのスイートがあり、32GBのMAC OSMojaveでは28秒かかります。 私たちの開発チームはWindowsとMacに均等に分かれており、その数は非常に再現性があります。

これが簡単なテストです-

it("works", () => {
  expect(1).toEqual(1);
});

私はcodesandboxでそれを入れて、それが瞬時にほとんど実行されます- https://codesandbox.io/s/4q8l0q52lw

私のWindowsマシンでは、4〜5秒かかりますが-

PASS src / index.test.js
v動作（62ms）

テストスイート：1合格、合計1
テスト：1合格、合計1
スナップショット：合計0
時間：4.158秒
すべてのテストスイートを実行しました。

テスト自体は62ミリ秒かかりましたが、残りのテストハーネスは4秒かかりました。 Enterキーを押してテストを再実行すると、同じ時間がかかります。

私の設定 -

> npx envinfo --preset jest

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD

WSL Ubuntuで試してみたところ、同じ結果（4〜5秒）が得られました-これらの設定-

  System:
    OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm

Jestを使い始めたばかりなので、非常に簡単なテストを行います。実行には15〜20秒かかる場合があります。 私はそれらを速く走らせたいです-そうでなければ私は思考の流れを失う傾向があります！

@bburnsは上記の問題を読んだ

@kensherman
糸の解像度でマイクロマッチ4を試してみてください。 それがウィンドウズでより良いかどうか見るためにお願いしますか？
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

私は真新しいMacBookProを使用しています。 MacOSとWindows10の両方に学生がいるので、ドライブにさらに2つのパーティションを追加することにしました。 1つはWindows10用で、もう1つはTuxeraNTFSを使用する共有ストレージ用です。

今日、ユニットテストを組み込んだJavaScriptレッスンを準備しているときに、この速度の問題に遭遇しました。 私は実際にMacOSからJestを実行していますが、コードとテストは共有NTFSパーティションにあります。 すべてのスイートがdescribe.skipとマークされている場合でも、シングルランモードとウォッチモードの両方で、Jestの完了には10秒以上かかります。

8つのスイート
42テスト

jestをmochaとchaiに交換すると、実行は約1秒のシングルと10ミリ秒の監視モードに戻りました。

ジェストをモカとチャイに交換すると、ランは約1秒のシングルと10ミリ秒のウォッチモードに戻りました。

基本的にあなたは私の最後の投稿を読んでいませんでした。 あなたはmocha/chaiを宣伝したかったのです...私たちは皆これについて知っています...私たちは冗談の回帰を修正しようとしています。 [私の投稿から] ...can you try with micromatch 4...を実行するのを手伝うか、これらの役に立たないコメントをスレッドに入れないようにしてください。 直接申し訳ありませんが、ある時点でそれを言う他の方法はありません。

@nasreddineskandrani [email protected]を試していますが、ウォッチモードで実行すると、実行が非常に遅くなることがあります。助けていただければ

@pachumon私が理解している限り、修正は

パフォーマンスの問題を取り除くには、jestの1つの依存関係を特定のバージョンに設定する必要があります（理論的には）修正はデフォルトでjest25に存在します=>開発者がこのhttps://github.com/を見つける方法を知るためにここを読んで

依存関係（マイクロマッチ）を修正が行われたバージョンに設定するには=>ここで確認できます小さなプロジェクトで例を示しました
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

package.json追加:( npmではなくyarn使用する必要があります）

...
  "resolutions": {
    "micromatch": "^4.0.0"
  }
...

お役に立てれば！ フィードバックを待っています

私のテスト実行時間も23.6.0の約2.5分から24.7.1と24.8.0の約15分に膨れ上がりました。 CIサーバーはWindowsを実行しており、このアップグレードによってビルド時間が同様に大幅に増加しました。 無駄に@nasreddineskandraniによって上述したように、私はmicromatch依存関係解決のオーバーライドを試みました。 これを診断するために私にできることがあれば教えてください。

@TomMahleこれは非常に悪いnewzです：（（私たちが一番上で話している回帰はすでに23.6にありました）
現在、単純な「サンプル」プロジェクトは優れたパフォーマンスを示しました。 マイクロマッチの更新後。
だから私たちはデバッグするために本当に問題のあるプロジェクトが必要です、あなたのプロジェクトはプライベートですか？ またはパブリック？

micromatch @nasreddineskandraniについての提案に感謝しますが、上記の@TomMahleのように、 ^4.0.0に固定してもパフォーマンスは向上しなかったようです。 😢

しかし、私はこの問題の診断に役立つかもしれない1つのファンキーなことを見つけました。

私は、ネイティブのWindowsシステムで、Windowsファイルシステムからマウントされたメインアプリディレクトリを備えたDockerコンテナで、jestを実行することができます。 非監視モードで実行すると、両方のシステムでほぼ同じ動作をするようです。これは、 @ thebearingedgeが示すように、

ただし、ウォッチモードでは、状況が少し異なります。ネイティブウィンドウは常に期待どおりに低速で動作しますが、Dockerコンテナーで実行するだけです。 テストスイートを2回実行するように指示すると（たとえば、 pを押してパターンを入力することにより）、1秒未満でテストを実行します（ネイティブウィンドウで同じことを実行するには3〜4秒かかります）。 dockerを使用することの唯一の欠点は、ファイル変更イベントがWindowsボリュームからdockerに伝播されないように見えることです。そのため、jestに自動的に実行させるのではなく、手動でEnterキーを押してテストを再実行する必要があります。当面の問題とは関係ありません。

@nasreddineskandrani。 残念ながら、私のプロジェクトは非公開です。 より小さなコードサンプル（jest config？）または私が提供できる統計があれば、私はそれを喜んで行います。 すべてのテストは劇的に遅いようです（Windowsのみ）ので、特定のテストとは関係がないと思います。

個人のWebサイト用に行っているDockerの作業を終了しています->（1週間以内に）これに戻ってきます。

@TomMahle
私はあなたが説明する問題でレポgithubを持っているように私の側を試みます。

1. テストはいくつありますか？
2. テストでdomモードを有効にしていますか？
3. それは反応しますか、それとも角張っていますか？
   ボーナス：
4. デバッグできるように、githubリポジトリで問題を再現してみてください。
   あなたは私のものをフォークすることができます： https ：
   または
5. たぶんあなたのテストマシンで私のレポを試してみませんか？ 結果を見ますか？ 23.6から24の間

マイクロマッチのメンテナには十分な注意が払われていたので、これはすでに解決されているに違いないと思いました。 Windowsでのjestテストの実行（つまり書き込み）は、現時点では非常に不快な経験です。

それ以来、mocha / chaiに移動しましたが、この問題がまだ解決されていないことに驚いています。

明確化

--runInBandを使用しましたが、感覚に基づいて、ユニットテストがさらに0.2秒ずつ少し遅くなったようです。

=> v24で試しましたか？ v23からv24まで、このシナリオでのみ優れた改善が見られます。
_ rerunでwatch 、1つのファイルに対して実行した場合のみ（最初の実行ではない）_
-> 2/3秒が0.4 / 0.5秒に低下します。
しかし、Macと比較して私は試したことがありません...だから多分それはまだ悪いです...現在の改善があっても

@SimenB

1. 問題のあるすべてのシナリオで、WindowsでのJest速度の回帰[v22とv23]として＃7110を検討します。
   ＃6783はそのうちの1つです

2.この問題は次のように考えることができます：すべての問題のあるシナリオでのjest [Mac vsWindows]の速度の問題。

投稿当時、両方のバージョンで試してみました。

単純な配列プッシュテストを使用した1つのテストで新しいプロジェクトを作成したところ、開始から完了まで10秒以上かかりました。 プロジェクトはreact / typescriptを使用していますが、テストファイルはreactコンポーネントファイルではなく、.jsのような通常のファイルです。 問題が何であるかを視覚化する方がよい場合は、以下のGIFを視覚的に参照してください。

初めてテストを実行すると、テストが9秒と推定されていることがわかりました。 完了すると、テストが完了するまで2回目のランダムな再試行が行われます。

上記のgif写真を撮ったとき（今回は2回目）、推定時間が少し短縮され、2回目の再試行は実行されませんでした。 それが予想される冗談の振る舞いであるかどうかはわかりません。

これは、別のプロジェクトでマイクロマッチ4を糸で実行している私のgifです。

Windows10と私のコンピューターの仕様の使用は次のとおりです。
AMD FX（tm）-83208コアプロセッサ3.50GHz
16GB RAM
x64
SSD

ここで私のプロファイリングを共有しましょう。
仕様：

• Windows 10 Pro
• ノード10.15.3
• Intel Core i7-4702MQ 2.2GHz
• 8GBのRAM
• x64
• SSD

手順：

1. npx create-react-app my-app --typescript
2. App.test.tsx
3. npm test実行します

CPUプロファイル：

CPU-20190801T141211.zip

15秒は、単一の些細なReactコンポーネントとテスト用のモジュールの要求にのみ費やされると予想されますか？

CPUプロファイリングの経験が豊富な人は見てみませんか？

112テスト
ウィンドウズ10
初回実行507秒
2回目の実行23秒
linuxサブシステム
ファーストラン54秒
2回目の実行29秒

85テスト
ウィンドウズ10
初回実行44秒
2回目の実行15秒
linuxサブシステム
初回実行26秒
2回目の実行15秒

Keproこれらの結果はmicromatch4でですか？

ここに100万通のメッセージを送るよりも、直接チャットするほうが好きです。同じトピックに関連するすべての問題を追跡するのは本当に地獄になりつつあります。
ここから参加できます。 https://gitter.im/wearefrontend/jest-slow-windows
私は今それに取り組んでいます...

Gitterは私の会社のVPNでブロックされています-素敵な人がここに意味のある更新を投稿できれば、それは驚くべきことです<3

あなたはまだいくつかのオープンソースをするために家で接続することができます：Pそしてそれをチェックする
ps dotaゲームはキューに入れるのにもっと時間がかかるので、この時間にgitterをチェックできます;）
これが現在の場所です：nodejs / node＃28946

@nasreddineskandraniあなたは私を手に入れました。 新しいMacBookを注文したので、到着するまでオープンソースのアクションはありません。 私は暇なときに実際に私のくだらないWindowsボックスで作業することを拒否します：D

問題がノード/ C ++レルムに移動したようです。ノード/ C ++レルムは、私の快適ゾーンの少し（非常に）外側にありますが、少し掘り下げます！

こんにちはこれに関するニュースはありますか？

複数のテストを開始する場合は、回避策として--runInBandを使用できます。 最初のテストを開始するにはまだ時間がかかりますが、次のテストは高速になります。

私のプロジェクトでは、すべてのテストを実行するのに21.803秒かかりました。
--runInBandを使用すると、7.412秒しかかかりません

--runInBandは、私にとってはさらに遅くします。 1200テスト。 runinBandなし70/50秒。 --runInBandを使用すると、せいぜい2回目の実行で90秒になります。
Linuxでは5〜8倍高速です

次に、-maxWorkers = 4を試してください。

@ cino893 、解決策ではありません:)回避策ではなく修正を見つけてください

それについて何かニュースはありますか？ そのバグのためにバージョン21にスタックしました。 v22は遅く、v23はさらに遅くなります。
優先度の高いバグだと思いませんか？

私が働いている場所では、OSを選択したり、UbuntuをWindowなどにインストールしたりする自由がありません。

@gombek v25を試しましたか？ Jestチームは、全面的にパフォーマンスを大幅に改善しました。

こんにちは、このディスカッションにいくつかの追加情報を追加したいと思いました。 Jestは、ホストシステム（Windows）からボリュームを介して共有されるソースコードとテストを持つDockerコンテナー内で実行された場合にも非常に低速です。

この速度低下は、UNIXシステムと比較してWindowsがファイルハンドルを処理する方法の違いによるものだと確信しています。 UNIXでは、プロセスのファイルハンドルが開いていて、他のプロセスがそのファイルを読み取るのをブロックしない場合。 Windowsでは、ファイルハンドルを保持しているプロセスは、ハンドルを解放する限り、そのファイルを所有します。 ファイル読み取りロジック、特にファイルハンドルがいつ、どのようにリリースされるかについて、Jestコードを調べます。 正常に動作するプログラムは、仕事が終わったらすぐにファイルハンドルを解放する必要があります。 Jestのようなテストランナーは、とにかくファイルハンドルを長時間保持する理由がないはずです。

@gombek v25を試しましたか？ Jestチームは、全面的にパフォーマンスを大幅に改善しました。

WindowsでJestv25を使用していますが、まだ遅いです

@pfftdammitchris Mac + Windowsでかなり複雑なテストスイートを比較しましたが、主にコールドキャッシュからいくつかの違いがあります。Windowsは著しく低速ですが、高温になると、2つの間で同様のパフォーマンスが得られます。

しかしながら...

特にWindowsで非常に注意すべきことの1つは、Carbon Black（または他のリアルタイムファイル監視ソフトウェア）のようなアンチウイルス/ファイルウォッチャーのような侵入的なカーネルレベルのプログラムです。 このようなものを実行している場合、Jestを実行するとパフォーマンスが大幅に低下することがあります。 テストを実行するのに数十分かかることについて話しています。

私は昨年、同じテストスイートがこれらのファイル監視プログラムを実行しているMacbook Proで最大30秒、Windowsラップトップで20分かかった会社で働いていました。

理由はわかりませんが、ファイルハンドルと、Jestがnode.jsファイルシステムAPIの一部をどのように使用するかと関係があると推測するのは危険です。

私は約20のテストしか持っておらず、jest --watchを使用して、最初の実行とEnterキーを押して再実行するタイミングの両方を実行しました。

Windowsでは両方の時間で約15秒かかりましたが、Linuxでは最初の実行で約5.3秒、その後の実行で2.3秒でした。

-t = "GARBAGE"を使用して、すべてのテストをスキップしてみました。 Linuxの場合は1.5秒かかりましたが、Windowsの場合は13秒かかりました。そのため、時間がかかっているのは実際のテストの実行ではないようです。

どちらのマシンも最新バージョンのnodeとjestを使用しており、Linuxは実際にはhyper-vを使用してWindows内で実行されているVMであるため、他の条件が同じであれば、Windowsの方が高速であると思います。

私は約20のテストしか持っておらず、jest --watchを使用して、最初の実行とEnterキーを押して再実行するタイミングの両方を実行しました。

Windowsでは両方の時間で約15秒かかりましたが、Linuxでは最初の実行で約5.3秒、その後の実行で2.3秒でした。

-t = "GARBAGE"を使用して、すべてのテストをスキップしてみました。 Linuxの場合は1.5秒かかりましたが、Windowsの場合は13秒かかりました。そのため、時間がかかっているのは実際のテストの実行ではないようです。

どちらのマシンも最新バージョンのnodeとjestを使用しており、Linuxは実際にはhyper-vを使用してWindows内で実行されているVMであるため、他の条件が同じであれば、Windowsの方が高速であると思います。

はい。 また、ソースコードをWindowsからLinux VMにマウントしてテストを実行すると、Windowsの場合と同じくらい遅くなります。 これは、前述したように、問題がJestのファイル処理ロジックにあることを強く意味します。

はい。 また、ソースコードをWindowsからLinux VMにマウントしてテストを実行すると、Windowsの場合と同じくらい遅くなります。 これは、前述したように、問題がJestのファイル処理ロジックにあることを強く意味します。

テストの実行中、CPUは高いが、ディスク使用量は高くないことに気づきました。 それはファイルハンドルのブロックと関係があり、CPUが低いと予想されます（jestがハンドルが解放されるのを待っているタイトなループにある場合を除く）

ファイルウォッチャーに関するhevans90のコメントを見ました。 サードパーティのアンチウイルスがインストールされていないか、同様のものがインストールされていませんが、Windowsに組み込まれているリアルタイム保護を無効にしても目立った違いはありません。

それを試してデバッグする時間がある人に何か助けがあれば、これを願っています。

そのため、今日、WindowsDefenderが大きな違いを生むことを確認しました。
以前はたくさんの除外がありましたが、新しい高速のラップトップを受け取ったとき、jestが1つのファイルを実行するのに10分以上かかった理由を一生理解できませんでした。

それから私は除外を思い出しました。
どの除外が違いを生むのか正確にはわかりませんが、ランナーを10分以上ではなく15秒未満に下げるようにしました

私は関連する除外の要点を見つけました（強力ではありますが）
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
ファイル拡張子.ts .js .spec.ts .spec.js .tsxも追加しました

どの除外が違いを生むのか正確にはわかりませんが、ランナーを10分以上ではなく15秒未満に下げるようにしました

うーん、私はそれを試しましたが、それは私のものには何の違いもなかったようです（私は数分もかからなかったので、おそらく私たちはさまざまな問題を経験しています）

とにかく、私は常に除外を設定しています。 実際、IntelliJ Ideaは、ワークスペースディレクトリを除外することを自動的に提案し、許可した場合はそれを行います（そうする必要があります）。 したがって、私の場合、速度の低下はWindowsDefenderやその他のウイルススキャナーによるものではありません。

パフォーマンスの違いは、Macと比較して5〜10倍です。 PCは強力なデスクトップマシンです（読む：macbookよりもはるかに高速です）。 他のすべては非常に速く、Jestだけがこの問題に苦しんでいます。

これに関する更新はありますか？ ...私は同じことを経験しています。各テストはセットアップとロードに長い時間がかかりますが、最初のテストがロードされた後、通常の速度で実行されます。

また、この問題があります。 単一のhelloworldテストを含む単一のテストファイル。起動には最大15秒かかり、さらにテストの実行にはさらに12秒かかります。

👋jestでtypescriptを使用していることを示唆する返信がいくつかあります-これは調べる価値があるかもしれません（ts-jestも使用している場合）： https ：

私にとっての変更は、（キャッシュなしで）冗談を30分待ってから、ほんの数秒になりました。

isolatedModulesフラグを設定すると、スペックファイルのタイプチェックが行われなくなる（および一部の機能が失われる）ことに注意してください： //github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

あなたの問題が冗談にあるかどうかを判断するのに役立つかもしれないので、私はこれをここに投稿するだけです。

👋jestでtypescriptを使用していることを示唆する返信がいくつかあります-これは調べる価値があるかもしれません（ts-jestも使用している場合）： kulshekhar / ts-jest＃908（コメント）

私にとっての変更は、（キャッシュなしで）冗談を30分待ってから、ほんの数秒になりました。

isolatedModulesフラグを設定すると、スペックファイルのタイプチェックが行われなくなる（および一部の機能が失われる）ことに注意してください： //github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

あなたの問題が冗談にあるかどうかを判断するのに役立つかもしれないので、私はこれをここに投稿するだけです。

ここに純粋なJavaScript。 私はこの問題を抱えているので、TypeScriptとは関係ありません。

参考： https ： https：//github.com/kulshekhar/ts-jest/issues/1115に関するフィードバックをお寄せ

また、この問題があります。 単一のhelloworldテストを含む単一のテストファイル。起動には最大15秒かかり、さらにテストの実行にはさらに12秒かかります。

Macで同じテストを実行しただけです。 開始には約1.5秒、テストの実行には1秒未満かかります。

ここではTSではなくJSも使用しています。

Jestを使用した純粋なJavaScriptもここにあります。 私はIntelの10genプロセッサを搭載した強力なクアッドコアラップトップを持っており、他のすべては非常に高速ですが、 [email protected]はいくつかの基本的なテストを実行するためにWindowsとLinuxで2〜3倍多くかかります。

同じ問題で、テストをWindowsで実行するのに約60秒かかり、最初の45秒ほどはUIが表示されません。 Linuxマシンでまったく同じテストスイートを実行し、実行が完了するまでに8秒かかりました。

上記の@Celluleのコメントは、約15秒まで劇的にスピードアップしました。

@ryanrapiniは@Celluleのアドバイスに従い（ただし、 Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusionsを通過しました）、一部のテストが13秒から6秒、つまり基本的に半分になることを確認しました。 ありがとう！

WebサイトのFAQページでWindowsDefender（または一般的にAV？）に言及するセクションを投稿したい人はいますか？ https://jestjs.io/docs/en/troubleshooting

ts-jestでisolatedModules: trueを使用すると、コールドスタートアップで大きな違いが生じたことを確認できます（〜10分=> 15秒）
jest 25に更新する前に、＃9457が解決されるのを待っているため、アルファ版での改善をテストしていません。

こんにちは、みんな、

ここでも同じ問題があり、解決策はありません...

現在いくつかのテストを行っている非常に単純なコードを実行します。
WesBoの「AdvancedReactCourse」からです。
彼はそれをMacで実行し、コンピューターから即座に回答を得ます。

そして私にとって：

テストスイート：スキップ2回、合格15回、合計17回中15回
テスト：スキップ6回、合格37回、合計43回
スナップショット：合格18、合計18
時間：5.869秒
すべてのテストスイートを実行しました。

isolatedModules: trueは私の場合は何も変更しません、私はまだ約5-6秒です。
そして、任意のオプションでテストを開始すると、9〜10秒かかります。

Defender Exceptionsにdevフォルダーを追加しても、何も起こりませんでした。

テストスイート：スキップ2回、合格15回、合計17回中15回
テスト：スキップ6回、合格37回、合計43回
スナップショット：合格18、合計18
時間：5.563秒
すべてのテストスイートを実行しました。

Windowsに良いオプションはありますか？
wsl2に行く必要がありますか？

こんにちは、みんな、

ここでも同じ問題があり、解決策はありません...

現在いくつかのテストを行っている非常に単純なコードを実行します。
WesBoの「AdvancedReactCourse」からです。
彼はそれをMacで実行し、コンピューターから即座に回答を得ます。

そして私にとって：

テストスイート：スキップ2回、合格15回、合計17回中15回
テスト：スキップ6回、合格37回、合計43回
スナップショット：合格18、合計18
時間：5.869秒
すべてのテストスイートを実行しました。

isolatedModules: trueは私の場合は何も変更しません、私はまだ約5-6秒です。
そして、任意のオプションでテストを開始すると、9〜10秒かかります。

Defender Exceptionsにdevフォルダーを追加しても、何も起こりませんでした。

テストスイート：スキップ2回、合格15回、合計17回中15回
テスト：スキップ6回、合格37回、合計43回
スナップショット：合格18、合計18
時間：5.563秒
すべてのテストスイートを実行しました。

Windowsに良いオプションはありますか？
wsl2に行く必要がありますか？

私のソリューションを適用して、何か効果があるかどうか教えてもらえますか？ （実際にはCelluleのソリューションですが、スクリプトを実行する代わりにメニューから実行しました）

私のソリューションを適用して、何か効果があるかどうか教えてもらえますか？ （実際にはCelluleのソリューションですが、スクリプトを実行する代わりにメニューから実行しました）

私のメッセージで言ったように、私はすでにそれをしました:)

私はあなたがしたことをメニューとすべてを通して従ったことを意味します。

Windowsでもこの問題が発生しています。 テスト自体は1秒未満で実行されますが、セットアップ全体の実行には最大15秒かかります。 v24とv26で試してみましたが、実際にはv26では少し遅くなります

私は次のいずれにも運がありませんでした（実行時間は改善されませんでした）：

• --runInBand追加
• maxWorkers
• @Celluleと@alessioalexによって提案されているように、 .ts .js .spec.ts .spec.js .tsx除外をVirus and Threat Protectionに追加します

ここのWindowsでの同じ問題は、バニラjavascriptと新しいtypescriptプロジェクトです。 mochaを使用して10ms未満で実行される9つのユニットテストを実行するために2秒。

狂ってる！

jestをグローバルにインストールするだけで、まったく同じプロジェクトが52（!!!）秒ではなく0.9秒で実行されます。
プロジェクトでnpm remove jest 、次に
npm install -g jest

もちろん、jestを開発者の依存関係としてプロジェクトに再び統合したいと思います。 なぜそれが起こるのか考えはありますか？

狂ってる！

jestをグローバルにインストールするだけで、まったく同じプロジェクトが52（!!!）秒ではなく0.9秒で実行されます。
プロジェクトでnpm remove jest 、次に
npm install -g jest

もちろん、jestを開発者の依存関係としてプロジェクトに再び統合したいと思います。 なぜそれが起こるのか考えはありますか？

これは間違いなくウイルススキャナーの問題のように聞こえます。 つまり、プロジェクトディレクトリはウイルススキャンの範囲内にあり、jestのクロール速度が低下しますが、グローバルnpmディレクトリはそうではありません。 ただし、これは単なる推測です。

@JPustkuchenと同じことを

プロジェクトフォルダをWindowsDefenderから除外しましたが、Jestの実行速度が低下しています。

これがまだ機能しているかどうかはわかりませんが、コードでタイプミスをすると、ウォッチモードでのテストがすぐに失敗することに気付きました。 これは、テストをコンパイルする前に、実際には新しいディレクトリのクロールを強制するものではないという考えにつながります。 非常に単純なテストでも、私にとっては10秒かかります。

誰かが少なくともこれが問題であることを認めてくれることを願っています。 今のところ、十分なパワーを備えた私のWindowsデスクトップマシン（読んでください：同僚のmacbookよりもはるかに多い）は、テストを実行するときにmacbookよりも約69倍遅くなります！ Jestテストの実行速度が非常に遅いため、フロントエンドコードに取り組むのは非効率的であるため、これは事実上フロントエンドコードに触れないように強制しています。 これが修正されない場合は、Jestから離れる必要があるかもしれません。 他のすべては非常に高速ですが、Jestテストは非常に低速です。 実際のテストロジックが実行されると、実際にテストを実行する以外のことに時間が費やされます。

もっと前向きなことに、私はこのバグに多大な感謝の念を抱いていると言いたいです。 私がメインの開発ワークフローをLinuxに切り替えることを決心したのは、これが最後の藁でした。 レガシープロジェクトに取り組む必要があるため、二度と戻らないとは言えませんが、ASP.NET Coreがクロスプラットフォームであるため、Windowsを再起動する理由は常に少なくなっています。

@ timrobinson33でトピックにとどまりましょう。 Nodeがどのプラットフォームでも問題なく動作することを考えると、 jestがWindows上の他のどの環境よりも68倍遅くなる理由はありません。 また、私は他のテストランナーでこの問題を経験したことがありません。

ベンチマークのjestgithubリポジトリでv26.4.2を使用してテストしました。
https://github.com/nasreddineskandrani/benchmark_jest
私のコンピューターのノードバージョン：v12.13.0

簡単なテストを更新するとかなり問題ありません（スクリーンショットを参照）。 私にとって、冗談は簡単なテストに適しています。
仕事に問題がある場合。 デフォルトでは問題ないため、問題を切り分ける必要があります。

@empperiは私のベンチマークリポジトリを試すことができます。 v26フォルダーの例で、このテストをマシンで実行するのにかかる時間を教えてください。 0.166msまたはその周辺でない場合は、問題が発生します。

ベンチマークのjestgithubリポジトリでv26.4.2を使用してテストしました。
https://github.com/nasreddineskandrani/benchmark_jest
私のコンピューターのノードバージョン：v12.13.0

簡単なテストを更新するとかなり問題ありません（スクリーンショットを参照）。 私にとって、冗談は簡単なテストに適しています。
仕事に問題がある場合。 デフォルトでは問題ないため、問題を切り分ける必要があります。

@empperiは私のベンチマークリポジトリを試すことができます。 v26フォルダーの例で、このテストをマシンで実行するのにかかる時間を教えてください。 0.166msまたはその周辺でない場合は、問題が発生します。

予想どおり、テストセットアップのパフォーマンスに違いはありません。 実際には、コンピューターよりも少し速く実行されます。 __tests__下に100個のテストファイルが含まれるようにテスト設定を変更しましたが、それらも正常に実行されます。 私たちのアプリはreact-scriptsを使用しているので、それを例に追加して、それが実際の問題を引き起こす可能性があるかどうかを確認しますが、パフォーマンスに違いはありません。

しかし、それから私はそれらのテストをWSL2 bash（NTFSファイルシステムに対して）とブームで実行しようとしました。実行時間は生のPowerShellのほぼ10倍です。 NTFSに対するWSL2ではI / O速度が遅くなることが予想されますが、このセットアップがいかに単純であるか（それぞれに単一のテストがある100個のテストファイル）を考慮すると、それほど影響はありません。 参考までに、これをWSL2bashで実行しました。

time find . -name "*.js" -print | xargs cat
...(file content prints omitted)...
real    0m0.138s
user    0m0.030s
sys     0m0.000s

これは、WSL2からファイルシステムを読み取るのに実質的にまったく時間がかからないことを示しています。 Powershellの同様のコマンドを参照するには：

> Measure-Command { ls *.js | % { cat $_ } }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 49
Ticks             : 499000
TotalDays         : 5,77546296296296E-07
TotalHours        : 1,38611111111111E-05
TotalMinutes      : 0,000831666666666667
TotalSeconds      : 0,0499
TotalMilliseconds : 49,9

これは、パフォーマンスが同じ球場にあることを示しています。

したがって、これに基づいて、問題はJestがI / Oを使用する方法が原因である可能性があり、それがWSL2のパフォーマンスに劇的な影響を及ぼしていると言えます。 私に問題を引き起こしているプロジェクトに関して言えば、コードとテストの問題のためにbashを必要としないことは簡単な作業ではありません（私はしません！）。 WSL2の人気が高まっていることを考えると、これは検討すべき本当の問題だと思います。

お役に立てれば。

：編集：

好奇心から、 --no-watchを使用してテストスイートを実行し、WSL2でファイルシステムを監視することが何らかの影響を与えるかどうかを確認しました。 答えはノーです、それは実際にはそれほど影響しません。

Windowsマシンでベンチマークを実行するには、約1.6秒かかります。 WSLを使用していません。
AVGアンチウイルスを使用していますが、リポジトリとノードの実行可能ファイルの両方に例外を追加しました。
私のハードドライブはSSDです。

ノードバージョンはv12.16.1

テストを更新すると、ファイルウォッチャーが即座にトリガーされますが、その更新の実行にかかる実際の時間は約1秒から2.4秒です。

問題となっているのが環境かどうかをテストしたかったのです。

私はこのリポジトリをいじっていました： https ：

• npm testに行くと、すべてのテストがウォッチモードで実行を開始します。
• 「p」を押してファイルのパターンを入力し、「tdd-02」と入力します。 実行時間は3秒以上になります。
  

Kent C. Doddsが有料コースで環境を台無しにした場合は驚きますが、もしそうなら、おそらくそこでデバッグできます：？ 彼のビデオでは、それは問題なく動作します。彼はMacを使用していると思います。

私は再び再現できない非常に奇妙なことに注意する必要があります-ファイルの1つ（tdd-02 ... js）とその隣のファイル（tdd-02 ... js）に対して、いくつかの連続したテストを再実行しました（ tdd-01 ... js）-約3秒。 コードはほとんど同じで、同じ依存関係を使用します。 そのため、実行速度の速いファイルからコードをコピーして、実行速度の遅いファイルに貼り付けました。その逆も同様です。 結果は同じでした。実行速度の遅いファイルは低速のままで、実行速度の速いファイルは高速のままで、実際のコードが交換されました。 これはおかしくなりつつあります。 これで、両方のファイルの実行速度が再び遅くなります（3〜6秒）。

@Glinkis最初の実行後に

@SimeonRolevあなたが投稿した例を見て、同じ手順でどのような番号が得られるかを確認します（パターン...）
更新：
try1：私はそれをuとして試し、あなたのステップを試したときに6秒を得ました->同じテストを再実行すると3秒に下がります（Enterキーを押します）
try2：ケントレポでjestを26.4にアップグレード-> 3秒の最初の実行でほぼ同じ
try3：ベンチマークテストリポジトリからindex.spec.jsファイルを取得しました。 そして私はそれをケントレポに落としました。 （他のすべてのテストファイルを削除する）->驚き2.8秒（昨日のテストがここに投稿されたので、SAME JEST 26.4.2、SAME COMPUTER、POWERSHELL、NODE_VERSIONなど...）

私はこのtry3をまだ理解していません=>私のファイルのケントリポジトリで再実行すると約3秒ですが、私のリポジトリでは再実行時に0.300秒に低下します（これをデバッグする誰かが必要です）
編集：ケントはこれをチェックするものでなければなりません：P

Enterキーを押すと、約200msでテストが実行されます。

@nasreddineskandraniその逆を試しましたか？ つまり、遅いリポジトリからあなたのリポジトリにテストをコピーしますか？ しかし、問題は私が投稿したレポにあるとは思いません。 はっきりとわかるように、多くの人が同じ問題を抱えています。私は再現可能な例を投稿していました。

@kentcdoddsあなたは

@SimeonRolev私のベンチマークでは、ません。 あなたはケントレポに何かを持っています。 これが遅くなる原因=>それ以外では冗談が速い。

このgithubの問題は、同じパフォーマンスに到達しなかったため、JestパフォーマンスウィンドウとmacOS / Linuxに関連しています。 彼らは私が推測するそれを条項しませんでした。 （2年前のjest v23よりもはるかに優れています）

こんにちは、私はここで同じ問題を経験しています。 私はWindowsマシンとWSLを持っています。 この動作をテストするために、プロジェクトファイルをWSLにコピーしました。 同じ2つの基本的なテストの実行は次のとおりです。
Windows 10（バージョン2004）：

WSL 2（Ubuntu 20.04）：

テストは非常に簡単です。

プロジェクトはCRAで作成されているため、設定を失敗させる構成はありません。Jestに関しては何も追加しませんでした。
同じテストがモカで非常に高速に、ほぼ瞬時に実行されます。 プロジェクトのテスト環境をセットアップしようとしています。本当にJestを使用したいのですが、テストを追加するにつれて、テストスイートはどんどん遅くなっていくようです。 各テストは0.8秒を追加しているようですが、何もしないのでばかげています。 Windowsでのテストの実行に問題があり、何がわからない。
問題はさらに悪化し、1回のテストに約15秒かかりましたが、-runInBandとを追加すると、状況は少し改善されたように見えましたが、モカウォッチモードが瞬時であることを考えると、まだ十分ではないと思います。

Yarnはバージョン1.22.5であり、他のすべてのnpm依存関係（reactやreact-scriptsなど）は最新です。

アンチウイルスとWindowsDefenderを無効にして、効果があるかどうかを確認しましたが、効果はありません。 また、プロジェクトフォルダのインデックス作成を無効にしましたが、どちらも役に立ちませんでした。

編集：Enterキーを押してみましたが、テストはWSLと同じくらい高速でした。

今、私は本当に混乱しています:)

しかし、これはまだ非常に遅いようです。何もしないことを考えると、各テストには0.3秒かかるようです。 このスイートは0.1秒以内に完了すると思います。

編集2：テストスイートに100個のテストを追加した場合、Enterキーを押して実行しても、実行に約44秒かかりました。

同じテストスイートは、WSLで約9〜10秒かかります。