<p>ada 25 pertunjukan</p>

Maaf tentang regresi tapi

maaf tidak dapat membagikan basis kode kami

berarti kita sama sekali tidak bisa berbuat apa-apa. Ini adalah pertama kalinya saya mendengar tentang kemunduran kinerja, di tempat lain saya pernah mendengar dari 10-40% _perbaikan_ dalam kinerja dari 24 menjadi 25. Anda perlu menyediakan semacam reproduksi, jika tidak, kami harus menutup masalah ini karena tidak dapat ditindaklanjuti sama sekali seperti yang ada.

Jika Anda ingin melihat ini ditangani, Anda harus meluangkan waktu untuk menyusun kotak reproduksi, atau berharap orang lain melakukannya.

ok saya akan melihat apakah saya dapat melakukan 10 tes paling lambat kami, kemudian mencoba menjalankannya dalam 24 vs 25. Sementara itu, apa yang Anda rekomendasikan sehubungan dengan membersihkan cache sebelum menjalankan tes di CI? lakukan? jangan lakukan itu?

Konfigurasi Anda, terutama transforms dan file setup mungkin relevan juga

apa yang Anda rekomendasikan sehubungan dengan membersihkan cache sebelum menjalankan tes di CI

Saya pribadi berpikir itu ide yang bagus hanya untuk memastikan tidak ada yang basi memberikan negatif palsu atau positif. Apakah itu membuat perbedaan besar pada runtime pengujian Anda untuk _not_ menghapus cache?

tampaknya sedikit lebih lambat ketika dijalankan setelah membersihkan cache. terima kasih atas tipnya, saya akan memeriksanya dan melihat apakah saya dapat mencoba repro

FWIW, saya juga memperhatikan bahwa v25 sedikit lebih lambat atau setara dengan v24. Belum melihat peningkatan yang mendekati 10-40%.

Saya melihat peningkatan signifikan pada lelucon 24 seperti yang disebutkan di sini: https://github.com/facebook/jest/issues/7811#issuecomment -577057189

Di atas diuji pada osx.

Namun, pengaturan yang sama persis berjalan jauh, jauh lebih lambat pada CI kami yang menjalankan CentOS.

Masalah khusus Linux? Masalah terkait I/O saat menulis file cache? Apakah mungkin untuk mematikan pembuatan cache sama sekali untuk mengesampingkan hal ini?

Saya pikir saya menemukan pelakunya dalam kasus kami, itu adalah bendera --collectCoverage . Saat dihapus untuk Jest 24 dan 25, pengujian kami berjalan kira-kira dua kali lebih cepat di bawah 25. Saat diaktifkan, pengujian kami di bawah 25 hampir 4 kali lebih lambat dari yang sama di bawah 24.

Ini dapat direproduksi baik pada OSX dan CentOS, jadi bertentangan dengan komentar saya sebelumnya, masalah ini tidak muncul khusus untuk Linux.

Menarik! Kami telah memperbarui Istanbul ke v3, mungkin ada sesuatu di sana yang mengalami kemunduran. Kami telah menambahkan dukungan untuk cakupan kode v8, jadi saya mungkin juga telah mengacaukan refactoring saat melakukannya

Ya! Itu konsisten dengan apa yang saya lihat juga. Kami menjalankan dengan cakupan di CI yang 2x lebih lambat. Dan ketika saya menjalankan secara lokal tanpa covg cukup cepat. @SimenB apakah ada opsi konfigurasi untuk menggunakan Istanbul yang lebih lama? :)

Menggemakan apa yang @csvan katakan akan lebih baik untuk mematikan pembuatan cache di CI jika itu memang penyebabnya karena kami tetap menghapusnya sebelum membangun

Saya tidak dapat mereproduksi ini - repo yang saya uji memiliki kinerja yang hampir sama dengan --coverage antara v24 dan v25. Apakah seseorang dapat mengumpulkan repositori dengan lelucon 24 dan lelucon 25 di mana peralihan di antara keduanya menunjukkan perbedaan?

baru saja menjalankan CI build kami dengan cakupan dinonaktifkan, saya pikir @csvan sedang melakukan sesuatu. Tes berjalan pada pukul 4:00 w/ cakupan dimatikan vs 11 menit w/ cakupan dihidupkan. Saya akan mencoba melihat apakah saya dapat membuat repro akhir pekan ini di beberapa titik.

exinfo kami dari agen build:

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 

Kami melihat masalah serupa. Memutakhirkan Jest 25 membuat pengujian kami lebih lambat saat menggunakan cakupan (166 dengan Jest 24 vs. 381 dengan Jest 25). Dengan Jest 25 menampilkan banyak kesalahan ini saat menjalankan pemeriksaan:

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 --->

Menurunkan ke Jest 24 membuat kesalahan itu hilang.

Saya juga melihat Jest 25 menangani collectCoverageFrom berbeda karena tampaknya mengumpulkan cakupan dari file yang telah kami nonaktifkan secara eksplisit dalam konfigurasi itu. Apakah dukungan untuk sintaks glob berubah di sana?

Adakah jejak JS sama sekali? Akan menarik untuk melihat di mana ia mati.

Saya juga memperhatikan Jest 25 menangani collectCoverageFrom secara berbeda karena tampaknya mengumpulkan cakupan dari file yang telah kami nonaktifkan secara eksplisit dalam konfigurasi itu. Apakah dukungan untuk sintaks glob berubah di sana?

Kami meningkatkan ke Micromatch 4, itu mungkin telah mengubah sesuatu. Namun, tidak ada perubahan yang disengaja. Bisakah Anda membuka masalah terpisah dengan reproduksi?

Adakah jejak JS sama sekali?

Ini dicetak:

==== 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-...

EDIT : Sebenarnya, saya melihat kesalahan tumpukan bahkan dengan cakupan dinonaktifkan.

Kami meningkatkan ke Micromatch 4, itu mungkin telah mengubah sesuatu. Namun, tidak ada perubahan yang disengaja. Bisakah Anda membuka masalah terpisah dengan reproduksi?

Akan melakukan.

Berdebar lagi. Cakupan jelas lebih lambat, dan tampaknya palsu. Inilah pengaturan waktu untuk 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

Pengaturan waktu untuk CI (travis).

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

@milesj apa itu sirkus v25?

Ini hanya pelari baru, yang seharusnya lebih cepat, tetapi tidak pernah dari apa yang saya lihat. https://www.npmjs.com/package/jest-circus

@EvHaus Jejak dari JSDOM menarik (mungkin juga sepenuhnya kebetulan, tentu saja). Bisakah Anda mencoba menginstal jest-environment-jsdom@24 dan menggunakannya? Kami memutakhirkan dari 11 menjadi 15, jadi sesuatu di sana mungkin telah berubah. Sepertinya tembakan panjang, tapi siapa tahu

@SimenB Mengembalikan hanya jest-environment-jsdom ke <24.0.0 di package.json pasti berdampak. Kesalahan heap out of memory hilang dan Jest tampaknya menyelesaikan prosesnya tanpa masalah.

Menarik! Jika Anda punya waktu, alangkah baiknya jika Anda bisa menguji

• 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

Atau cukup tautkan di jsdom dan bagi dua. Saya akan melakukannya besok, tetapi saya belum benar-benar memiliki reproduksi yang baik

Untuk tes berikut, saya tidak mengaktifkan cakupan.

• Dengan [email protected]
  
  
  
  • 143 detik untuk menjalankan tes
  
  
  • Tidak ada masalah
  
  
• Dengan [email protected]
  
  
  
  • 154 detik untuk menjalankan tes
  
  
  • Tidak ada masalah
  
  
• Dengan [email protected]
  
  
  
  • 228 detik untuk menjalankan tes
  
  
  • Banyak kesalahan JavaScript heap out of memory
  
  

Jejak tumpukan

Ini adalah beberapa jejak tumpukan dari jest-environment-jsdom-fourteen run:

==== 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 

Semoga ini membantu

Saya tidak tahu apakah ini akan membantu, tetapi organisasi saya mengalami perlambatan besar-besaran dari Jest 24 menjadi Jest 25 (18 menit menjadi 28 menit) yang hilang setelah mematikan koleksi cakupan (turun menjadi 10 menit).

@rosasynstylae karena penasaran, apakah kode Anda memiliki banyak tes snapshot?

@benmonro Benar, ya.

Begitu juga milik kita! @SimenB menurut Anda banyak snapshot dalam repo yang dapat menyebabkan ini?

Kami mengalami masalah kinerja tanpa snapshot. Kami sedang mengumpulkan liputan. Perlambatan signifikan dari 24 -> 25. 2 proyek berbeda. Ini bervariasi tetapi perlambatannya signifikan dan konsisten.

Saya dapat menjalankan tes berulang-ulang tanpa perubahan dan tes rata-rata 10 kali lebih lambat daripada 24.

Saya beralih kembali ke 24 dan larinya kembali ke kecepatan yang biasa kami lakukan.

Saya dapat memberikan info lebih lanjut jika diperlukan. Saya ingin memastikan untuk menyebutkan 2 proyek kami tanpa tes snapshot.

Dari semua komentar di sini, sepertinya masalah liputan, dan mungkin kemunduran di istanbul?

Dari semua komentar di sini, sepertinya masalah liputan, dan mungkin kemunduran di istanbul?

Saya tidak akan begitu cepat untuk menunjukkan jari di istanbul. Dalam kasus saya, bahkan dengan cakupan dinonaktifkan, saya melihat masalah kinerja dan stabilitas yang signifikan di Jest 25. Lihat https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Mungkin ada dua masalah terpisah:

1) Masalah dengan jest-environment-jsdom-fourteen, dan
2) Masalah dengan cakupan istanbul

Saya menurunkan micromatch menjadi ^3.0.0 dan melihat peningkatan besar-besaran menggunakan --coverage , kurang lebih kembali ke kinerja yang kami lihat di Jest 24. Adakah yang bisa mereproduksi?

PEMBARUAN: Namun, sekarang berjalan tanpa --coverage juga kembali ke level kinerja Jest 24 - dua kali lebih lambat :-/

@EvHaus terima kasih telah memeriksa, sangat menarik! Sayangnya, saya masih tidak dapat mereproduksi ini. Jadi reproduksi akan tetap luar biasa, dengan begitu saya dapat mencoba men-debug ini.

Saya menurunkan micromatch menjadi ^3.0.0 dan melihat peningkatan besar-besaran menggunakan --coverage , kurang lebih kembali ke kinerja yang kami lihat di Jest 24. Adakah yang bisa mereproduksi?

PEMBARUAN: Namun, sekarang berjalan tanpa --coverage juga kembali ke level kinerja Jest 24 - dua kali lebih lambat :-/

Apa sih... Sejauh yang saya bisa lihat di istanbul tidak ada yang bergantung pada micromatch, jadi mengapa itu berdampak pada cakupan di luar jangkauan saya

Seluruh kinerja micromatch menjadi agak tidak masuk akal, dengan cakupan v3 lebih cepat dari v4, tanpa v4 lebih cepat dari v3? 😅

@SimenB ya, jalankan melalui CI kami juga hanya untuk mengonfirmasi. Tidak mengubah apa pun selain menambahkan

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

ke package.json kami memangkas 6 menit tanpa henti saat menggunakan --coverage , membawanya secara kasar kembali ke apa yang kami lihat di bawah Jest 24.

Sejauh yang saya bisa lihat di istanbul tidak tergantung pada micromatch

Menemukan komentar ini di utas lain yang mungkin terkait dengan ini:

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

Hanya mengkonfirmasi apa-apa di istanbul menarik micromatch (mereka menggunakan minimatch di plugin babel).

Mungkin ada sesuatu tentang pengecualian yang tidak berfungsi dengan baik, pasti. Kami menggunakannya untuk memeriksa instrumen apa yang harus kami gunakan: https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. Bisakah Anda memasukkan beberapa login di sana dan melihat apakah kami mengembalikan true mana saja dengan micromatch@4 yang tidak kami lakukan untuk micromatch@3 ?

Pasti terasa seperti 2 masalah terpisah, satu tentang jsdom dan satu tentang liputan

Saya dapat mengonfirmasi itu kembali ke kecepatan normal untuk kami di CI ketika kami menyelesaikan micromatch@3 juga.

Jest + TypeScript + reaksi basis kode di sini. Melihat masalah ini dan menggunakan npm-force-resolusi untuk memaksa micromatch ^3.0.0 tampaknya memperbaiki pelambatan yang gila.

Apakah Anda memiliki pola file uji khusus pr pola cakupan di konfigurasi Anda?

@EvHaus Saya sangat tertarik jika Anda melihat perbedaan dengan menurunkan versi Micromatch juga, mengingat Anda melihat perbedaan besar dengan versi jsdom

Jika ini yang Anda maksud, maka ya.

  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/**/**',
  ],

kami juga memilikinya dan milik kami terlihat sangat mirip dalam hal panjang/nilai

@Ancient123 ya, tepatnya. Tampaknya terkait dengan regresi Micromatch untuk pola yang dinegasikan. Terima kasih!

Tampaknya terkait dengan regresi Micromatch untuk pola yang dinegasikan. Terima kasih!

Tercatat, saya akan memeriksanya secepatnya.

Seluruh kinerja micromatch menjadi sedikit tidak masuk akal

Maaf tentang penurunan kinerja. Menghasilkan ekspresi reguler untuk globbing jauh lebih sulit dilakukan daripada yang terlihat. Terutama ketika perlu menangani negasi dan bersifat lintas platform. Saya sedang menyelidiki ini sekarang.

@jonschlinkert itu tidak bermaksud menuduh sama sekali, pekerjaan yang Anda lakukan di Micromatch dan perpustakaan terkait sangat dihargai! :jantung:

Ya! apa yang dikatakan @SimenB . tidak lain hanyalah ❤️

@EvHaus Saya sangat tertarik jika Anda melihat perbedaan dengan menurunkan versi Micromatch juga, mengingat Anda melihat perbedaan besar dengan versi jsdom

Di package.json saya, saya mengatur:

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

Jalankan ulang npm install , dan kemudian dihapus secara manual node_modules/jest/micromatch (yang pada versi 4). Kemudian jalankan kembali tes saya.

Sayangnya, saya masih melihat banyak kesalahan "JavaScript kehabisan memori".

Apakah saya melakukan downgrade dengan benar?

resolutions membutuhkan yarn , npm belum mengimplementasikannya (ada di peta jalan untuk v7: https://blog.npmjs.org/post/186983646370/npm- cli-roadmap-summer-2019)

@EvHaus hingga npm v7 keluar, Anda dapat menggunakan resolusi dalam npm dengan paket ini: https://www.npmjs.com/package/npm-force-resolusi

Maaf atas keterlambatannya. Digunakan npm-force-resolutions (yang melakukan hal yang benar) untuk mengunci micromatch ke v3. Sayangnya, itu tidak membuat kesalahan tumpukan saya hilang.

Jadi bagi saya, masih [email protected] harus disalahkan, seperti yang disebutkan di sini: https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Menyelesaikan jsdom ke thirteen adalah yang memperbaikinya.

Adakah yang pernah mengalami penurunan kinerja di 25 memiliki masalah yang tidak diperbaiki dengan menggunakan jsdom@13 atau micromatch@3? Kebocoran memori di JSDOM sedang diperbaiki (https://github.com/jsdom/jsdom/pull/2840 dan berbagai masalah/PR terkait darinya) dan regresi dalam micromatch telah dilaporkan dan sedang dikerjakan: https:// github.com/micromatch/micromatch/issues/179.

Versi tetap JSDOM telah dirilis, Anda dapat menggunakannya dengan menginstal jest-environment-jsdom-sixteen . @EvHaus dapatkah Anda memverifikasi itu memperbaiki masalah Anda?

@SimenB masalah saya mungkin tidak terkait, tetapi saya mencoba jest-environment-jsdom-sixteen vs menggunakan default, dan melihat peningkatan 20-an dalam runtime untuk rangkaian pengujian yang sama selama menjalankan berulang.

lebih menggunakan v15 (yang dikirimkan dengan lelucon secara default) dan tidak ada perubahan lain? Bisakah Anda menguji dengan 16.1.0 juga (meskipun itu membocorkan memori, jadi mungkin lebih sulit untuk diuji). JSDOM baru saja mendarat dengan dukungan elemen khusus, _mungkin_ ada regresi di sana? Tidak yakin

Versi tetap JSDOM telah dirilis, Anda dapat menggunakannya dengan menginstal jest-environment-jsdom-sixteen. @EvHaus dapatkah Anda memverifikasi itu memperbaiki masalah Anda?

Sayangnya masih mendapatkan kesalahan tumpukan dengan jest-environment-jsdom-sixteen . Versi kerja stabil terakhir dari JSDom bagi saya adalah jest-environment-jsdom-thirteen .

Versi tetap JSDOM telah dirilis, Anda dapat menggunakannya dengan menginstal jest-environment-jsdom-sixteen . @EvHaus dapatkah Anda memverifikasi itu memperbaiki masalah Anda?

Lingkungan bekerja dengan basis kode kami, tetapi kami masih melihat regresi hampir 100% dalam waktu proses. Secara anekdot jest-environment-jsdom-sixteen tampaknya meningkatkan kinerja waktu berjalan sebesar 10% hanya ketika menggunakan 25.1 vs 24.9

Hai @SimenB ,

Saya telah membuat kasing yang dapat direproduksi di sini https://github.com/olebedev/jest-perf-issue . Silakan lihat. Di bawah hasil untuk membandingkan. /cc @joscha

Hasil

Tolok ukur dijalankan pada MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz .

| versi lelucon | cabang | waktu |
|:--------------|:------:|----------:|
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

Dalam kasus kami, di mana lelucon v25.1 ~50% lebih lambat dibandingkan dengan v24.9, sekarang lelucon terbaru v25.2.0 bahkan 20% lebih lambat dibandingkan dengan v25.1

@olebedev Woah, itu menyakitkan

Saya mendapatkan nomor yang mirip dengan Anda. Jika didasarkan pada proyek nyata, saya sarankan menggunakan cakupan v8. Dibutuhkan runtime dari 600-an hingga 35-an di mesin saya dalam reproduksi Anda. Alasan perbedaan besar mungkin karena kami tidak mencoba untuk menginstrumentasikan file yang tidak tercakup dengan cakupan v8 (kami hanya mengatakan setiap byte tidak ditemukan, yang berfungsi dengan v8).

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

Tidak yakin mengapa ini sangat lambat... Saya akan mencoba mencari waktu untuk melihat ke dalamnya (tidak akan dalam waktu dekat). Setidaknya tidak lebih lambat di v25 daripada v24

Apakah saya memahami dokumen dengan benar bahwa kita dapat menggunakan cakupan v8 bersama-sama
dengan lingkungan ...-sixteen ?

Bersulang,
J

Pada Rabu, 8 Apr 2020, 22:33 Simen Bekkhus, [email protected] menulis:

@olebedev https://github.com/olebedev Woah, itu menyakitkan

Saya mendapatkan nomor yang mirip dengan Anda. Jika didasarkan pada proyek nyata saya
merekomendasikan menggunakan cakupan v8. Dibutuhkan waktu proses dari 600 detik hingga 35 detik di my
mesin dalam reproduksi Anda. Alasan perbedaan besar itu mungkin karena
kami tidak mencoba untuk memasukkan file yang tidak tercakup dengan cakupan v8.

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

Tidak yakin mengapa ini sangat lambat... Saya akan mencoba mencari waktu untuk memeriksanya.
Setidaknya tidak lebih lambat di v25 daripada v24

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

Ya, baik jest-environment-jsdom-sixteen , atau jest-environment-node dibundel. Perhatikan juga bahwa itu hanya didukung pada node 10+, bukan node 8.

(Saya hanya pernah menguji ini dengan Node env, tetapi jika tidak berfungsi dengan jsdom env itu bug - silakan buka masalah terpisah )

jest-environment-jsdom-sixteen + v8 sebagai penyedia cakupan lebih buruk sekitar 20% bagi kami pada jest 25.3.0, node 12.16. Kami juga mencoba men-debug mengapa kinerja pengujian kami memburuk sekitar 80% dari 24 hingga 25 lelucon.

@joual apakah Anda mencoba solusi micromatch (turunkan versi ke 3.x)?

Memiliki pengalaman serupa di sini, waktu pengujian (_tanpa_ cakupan) berlipat ganda pada v25 dari 35-40 detik menjadi 80-90 dan terkadang lebih. Mencoba mengunci micromatch di v3, tidak ada perbedaan yang terukur. Fwiw, kami memiliki sekitar 3k tes dimana 58 adalah tes snapshot.
Mencoba untuk menurunkan versi jsdom tetapi ini tampaknya memperkenalkan banyak kerusakan pengujian karena fitur terbaru yang kami gunakan. Akan melihat apakah saya bisa menyiasatinya dan melaporkan kembali.

@SimenB Cakupan mengumpulkan pekerjaan pada proyek yang lebih cantik juga sangat lambat, dapatkah Anda memeriksanya? https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest mengumpulkan liputan, pekerjaan lain tidak.

Memiliki pengalaman serupa di sini, waktu pengujian (_tanpa_ cakupan) berlipat ganda pada v25 dari 35-40 detik menjadi 80-90 dan terkadang lebih. Mencoba mengunci micromatch di v3, tidak ada perbedaan yang terukur. Fwiw, kami memiliki sekitar 3k tes dimana 58 adalah tes snapshot.
Mencoba untuk menurunkan versi jsdom tetapi ini tampaknya memperkenalkan banyak kerusakan pengujian karena fitur terbaru yang kami gunakan. Akan melihat apakah saya bisa menyiasatinya dan melaporkan kembali.

Sedang bereksperimen dengan versi jsdom yang berbeda hari ini di jest@24 (yang secara default v11). Hingga v14 semuanya tampak berfungsi dengan baik, tetapi pada v15 uji coba memakan waktu 50-60% lebih lama secara konsisten. Cerita yang sama di v16. Akan melihat apakah saya bisa mendapatkan performa serupa di jest@25 dengan menurunkan versi jsdom ke v14.

[email protected] memiliki beberapa perbaikan memori, @EvHaus dapatkah Anda mencobanya? --detect-leaks milik Jest sendiri menemukan kebocoran pada versi sebelumnya, tetapi tidak pada 16.2.2.

Saya juga mendapatkan beberapa peningkatan lain jika Anda memiliki banyak symlink (yang sangat lambat di windows), jadi jika orang dapat mencoba [email protected] itu akan menyenangkan

@SimenB Apa cara termudah untuk mengujinya? Jika saya menambahkan [email protected] secara langsung sebagai devDependency Jest mengabaikannya dan menggunakan apa pun yang dibundel dengan jest-environment-jsdom yaitu 15.2.1 hari ini.

Bagaimana saya bisa menipu npm untuk memastikan itu menggunakan versi jsdom yang saya inginkan?

Instal jest-environment-jsdom-sixteen dan gunakan https://jestjs.io/docs/en/configuration#testenvironment -string

Alpha diterbitkan, sehingga Anda dapat mencoba jest@next - ia datang dengan jsdom 16 di luar kotak

@SimenB Maaf, kurang beruntung dengan [email protected] dan [email protected] . Masih mendapatkan banyak kesalahan ini:

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

Dan akhirnya pelari itu mati.

Detail saya:

> 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 

Berikut adalah beberapa tumpukan penuh yang dikembalikan dari itu:

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

Sayang sekali Apakah itu dengan atau tanpa pertanggungan?

Itu tanpa liputan. Seharusnya diklarifikasi.

Apakah menurut Anda saya menjalankan versi Node (v10) yang cukup lama akan menjadi faktor dalam hal ini?

Anda dapat mencoba menggunakan versi yang lebih baru, jika tidak ada yang lain itu akan menjadi titik data yang menarik. Hal lain yang harus dicoba adalah mencoba membuat heap dump tepat sebelum mati. Apa yang ada di tumpukan?

Sangat menarik bahwa tidak ada yang menyebutkan bahwa micromatch@4 tidak https://github.com/micromatch/micromatch/pull/151 dan https://github.com/facebook/jest/pull/10131 memperkenalkan hilang caching di sisi lelucon.

Bagi saya downgrade ke micromatch@3 dan upgrade ke jest-environment-jsdom-sixteen menghemat 50% waktu.
Tetapi dengan jest 26 dan jsdom bawaan saya masih mendapatkan kesalahan kebocoran saat menjalankan lelucon dengan --detectLeaks dalam kasus saya. Mencoba repo segar dan semuanya berfungsi dengan baik.

https://github.com/facebook/jest/pull/10131 digabungkan!! <3

Dirilis pada 26.1.0, sangat tertarik untuk mendengar jika itu membantu orang-orang

@SimenB terima kasih banyak atas rilisnya! sayangnya di pihak kami, kami masih menghadapi perbedaan besar:

saat ini:

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

pada setiap versi yang lebih tinggi dari 24.9

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

baik dengan cache baru dan setelah penginstalan ulang lengkap semua modul node. konfigurasi yang tidak tersentuh.
menjalankan tes pada mode arloji, dibutuhkan lebih dari 3 menit di mesin saya untuk menentukan tes mana yang harus dijalankan. saya tidak dapat benar-benar mengisolasi masalah untuk reproduksi tetapi jika Anda memberi saya beberapa saran apa yang harus diuji, saya akan sangat tertarik. terima kasih untuk semua pekerjaan yang Anda lakukan untuk itu!

@SimenB

Untuk proyek prettier , masih lebih lambat dari v24 saat mengumpulkan liputan.

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

Saya dapat mengonfirmasi bahwa kinerja versi 25 dan 26 lebih rendah dari 24 di Bitbucket Pipeline. Saya juga memperhatikan bahwa kelambatan meningkat dengan cakupan diaktifkan. Versi 25 menjadi lebih buruk dibandingkan dengan versi 26 dan saluran pipa macet karena penggunaan memori.

@SimenB Saya melakukan git bisect untuk mencari tahu di mana regresi kinerja antara 24.9 dan 25.1 diperkenalkan. Saya menggunakan tes yang lebih cantik karena berjalan tanpa modifikasi dari 24,9 hingga 26,1.

Saya membandingkan akumulasi runtime dari tiga run dari subset js (untuk mengamankan beberapa waktu) dengan cache yang dinonaktifkan. Lebih khusus perintah yang saya gunakan adalah ( yarn run jest --no-cache tests/js/ ) dengan node 10.19. karena node 10 adalah versi yang direkomendasikan untuk 24.9.

Hasil:

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)

Karena ada fallback jika compileFunction tidak ditentukan, saya menghapus cabang compileFunction dari ad5377333daf6716af3465bba39f86b7db485e2b yang memulihkan kinerja.

Melihat 26.1 kode telah bergerak sedikit tetapi compileFunction dan fallback masih ada. Jadi:

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

yaitu menghapus cabang compileFunction ( patch ) membawa 26.1 kembali ke runtime 24.9. Saya yakin itu bukan solusinya, tapi setidaknya kita punya sesuatu untuk dikerjakan.

Sebagai titik data lain, jest suite kami saat ini membutuhkan waktu sekitar 2767 detik dengan [email protected] dan di MR pembaruan kami dibutuhkan sekitar 3497 detik, meningkat sekitar 27%.

Terima kasih atas semua kerja bagusnya, tim lelucon, saya harap keterampilan detektif @wurstbonbon dapat membantu Anda memperbaiki regresi itu!

@wurstbonbon terima kasih telah meluangkan waktu untuk menggali! Sangat menarik bahwa compileFunction lebih lambat... Itu berarti Anda dapat menggunakan lingkungan pengujian khusus alih-alih menerapkan tambalan.

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(dan sama untuk jsdom env). Bisakah kamu mengkonfirmasi?

Namun, kemacetan seperti itu terdengar aneh - Node sendiri beralih menggunakannya 18 bulan yang lalu: https://github.com/nodejs/node/pull/21573 . Jadi mungkin ada sesuatu yang aneh yang kita lakukan di pihak kita. https://github.com/nodejs/node/issues/26229 yang ditautkan sangat menarik - mungkin kita perlu melakukan caching lagi di pihak kita?

@SimenB saya baru saja mencoba sesuatu yang mirip dengan custom env itu dan sepertinya itu sedikit lebih baik (tapi masih lebih lambat dari lelucon 24).

Saya harus melakukan MyNodeEnv.prototype.getVmContext = null; , karena saya menguji dengan lelucon 26, dan sepertinya memeriksa if (typeof this._environment.getVmContext === 'function') { now . Tidak yakin apakah ini dapat menyebabkan masalah lain.

Ini adalah hasil yang saya lihat setelah beberapa kali berjalan:

Bercanda 26 w/testEnvironment: "simpul" => ~280s
Jest 26 dengan lingkungan pengujian khusus => ~210s
Lelucon 24 => ~160s

Beri tahu saya jika saya dapat membantu dengan informasi lain atau sesuatu yang lain!

Seperti yang diharapkan, custom env menghasilkan percepatan yang sama untuk lebih cantik.

Saya juga sudah mencobanya di basis kode kami di mana perbedaannya ~270s vs ~200s jadi hanya sekitar 25% dan bukan pengurangan 40%. Sayangnya saya tidak dapat menjalankan pengujian kami dengan lelucon 24 karena kami mengandalkan tiruan penghitung waktu modern yang baru.

Saya melewatkan delete dalam contoh saya di atas, maaf tentang itu.

Saya ingin tahu apakah cukup dengan men-cache fungsi yang dikompilasi secara manual - dapatkah Anda mencoba menerapkan tambalan ini? (baik JS yang ditranskripsikan dan sumber TS disertakan di sini)

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.',
       );

Saya pikir ini mungkin berhasil.

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);
}

Ini meningkatkan kinerja sedikit tetapi Script masih jauh lebih cepat.

Mencoba rekomendasi dari @SimenB : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs?commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

Meskipun sedikit meningkatkan kinerja, itu masih jauh lebih lambat daripada lelucon 24.x:

• Jest 24.x: 2580 detik total runtime dari tes lelucon kami
• Jest 26.x: 3166 detik total runtime dari tes lelucon kami

@leipert Pernahkah Anda mencoba menurunkan lingkungan jsdom ke 14?

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" di konfigurasi lelucon Anda. Ini tampaknya masih bertanggung jawab atas sebagian besar peningkatan durasi bagi kami (menambahkan 40-50%) tetapi mulai terlihat seperti ada beberapa regresi yang dimainkan.

@pleunv Dengan jest 24.x kami menggunakan jsdom 16 dengan jest-environment-jsdom-sixteen , kami harus memutakhirkan karena beberapa masalah dengan pengujian komponen web. Jadi satu-satunya perubahan yang kami lakukan: jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom , jadi versi jsdom bahkan tidak berubah.

Membuka https://github.com/nodejs/node/issues/35375 upstream tentang masalah yang ditemukan oleh @wurstbonbon

@SimenB apakah Anda mengetahui alternatif yang layak untuk micromatch? Repo itu telah diam selama lebih dari setengah tahun sekarang, dan masalah utama yang memengaruhi Jest seperti https://github.com/micromatch/micromatch/issues/179 masih terbuka.

Tidak juga, itulah yang digunakan sebagian besar perpustakaan. Bisa melihat misalnya minimatch, tapi saya ragu itu akan layak

@SimenB Apa yang membuat micromatch lebih baik dari semua alternatif?

Berdasarkan umpan balik dalam masalah yang saya buka, saya pikir kita harus kembali menggunakan Script untuk saat ini karena tampaknya perlu sedikit perbaikan di Node untuk memperbaikinya di sana.

@leipert @wurstbonbon atau siapa pun, dapatkah Anda mencoba tambalan ini di 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) {

Saya menguji tambalan untuk menggunakan Script pada suite pengujian kami dan inilah hasil yang saya dapatkan
Waktu dalam min:sec

Nama | Suite 1 | Suite 2 | Suite 3 | Suite 4
-- | -- | -- | -- | --
lelucon 24 | 3:25 | 3:30 | 3:29 | 0:53
lelucon 26 ditambal | 3:32 | 4:36 | 3:48 | 0:53
jest 26 belum ditambal | 5:10 | 6:12 | 5:11 | 1:07
26 ditambal vs 24 | 4% | 31% | 9% | 1%
26 belum ditambal vs 24 | 52% | 76% | 49% | 27%
26 ditambal vs tidak ditambal | 46% | 35% | 36% | 25%

masih menarik v26 masih belum membaik di v24...

Terima kasih @Cellule! Itu cukup baik untuk saya - saya akan membuat PR ketika saya punya waktu

Hal-hal yang luar biasa! Itu hanya menyisakan masalah Micromatch, semoga repo itu akan berada di bawah pemeliharaan aktif lagi.

BTW, saya berasumsi ada juga regresi perf di JSDOM. Ketika saya melakukan tes seperti itu pada proyek web besar. Tidak ada tambalan yang disebutkan di atas yang diterapkan.
Dan itu tampak seperti itu.

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)

Tentunya ini adalah laporan kinerja yang sangat kabur dan tidak stabil yang harus saya tinggali, tetapi saya pikir setiap masukan membantu :)

https://github.com/facebook/jest/releases/tag/v26.5.0 memiliki vm.Script perubahan yang dibahas di sini

(Sunting: diperbarui setelah berjalan tambahan)

Hasil awal pada rangkaian tes yang sama:

bercanda 26,5
Dingin: 59,992
Panas: 43,976

lelucon 26.4:
Dingin: 90.213
Panas: 47.408

Percepatan yang sangat signifikan pada cold run <3

Dan inilah hasilnya dengan rangkaian pengujian saya:

bercanda 26,5
Dingin: 149 detik

bercanda 26.4
Dingin: 226 detik

Berita bagus Saya pikir kita kembali ke regresi micromatch, kalau begitu

Jika kalian menggunakan npm-force-resolutions untuk menginstal paksa micromatch 3. Ini mungkin tidak berfungsi di [email protected]

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

Kesalahan saat menjalankan tes:

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 Terima kasih banyak atas pembaruannya. Ini menghemat 20% waktu berjalan di Travis setelah memperbarui ke [email protected]

Hasil kami:

Ini adalah v26.5

• 323.98 detik
• 321.24s

Ini adalah v24.9

• 262.17 detik
• 275.96 detik

Terima kasih @SimenB! Ini luar biasa. Hasil kami untuk ~22000 pengujian kami di ~2000 suite:

• Lelucon 24.x: 2864 s
• Lelucon 26.5.2: 2967 s

yang sekitar 3% lebih lambat dan dengan demikian dalam margin kesalahan, dibandingkan dengan ~27% perlambatan yang kita lihat sebelumnya. Terima kasih, sekarang kita hanya perlu menggabungkan: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Hanya ingin mencatat bahwa semua masalah "tumpukan memori" yang saya alami sebelumnya hilang setelah memutakhirkan ke Jest 26.5.2 dan Node 14 (ada di Node 10 sebelumnya). Tidak yakin berapa banyak masalah yang disebabkan oleh Jest vs. oleh Node, tetapi jika orang lain melihat masalah serupa, coba tingkatkan ke keduanya.

PEMBARUAN : Tidak apa-apa. Saya mulai mendapatkan kesalahan OOM lagi. Saya kira itu tepat di batas apa yang bisa ditangani laptop saya dan beberapa putaran pertama bagus, tapi sekarang sekarat lagi. Harus tetap berpegang pada 24.xx :(

Jika seseorang tertarik, saya telah membuat DOM yang memiliki kinerja yang sangat baik dibandingkan dengan JSDOM. Ini memiliki dukungan untuk Jest.

| Operasi | JSDOM | Selamat DOM |
| ------------------------------------ | ------- | --------- |
| Impor / Perlu | 333 md | 45 md |
| Mengurai HTML | 256 md | 26 md |
| Serialisasi HTML | 65 md | 8 md |
| Render elemen khusus | 214 md | 19 md |
| querySelectorAll('tagname') | 4,9 md | 0,7 md |
| querySelectorAll('.class') | 6,4 md | 3,7 md |
| querySelectorAll('[atribut]') | 4,0 md | 1,7 md |
| querySelectorAll('[class~="name"]') | 5,5 md | 2,9 md |
| querySelectorAll(':nth-child(2n+1)') | 10,4 md | 3,8 md |

Tautan ke proyek:
https://github.com/capricorn86/happy-dom/

@ capricorn86 Terlihat bagus. Apakah sesuai dengan spesifikasi?

@ capricorn86 Terlihat bagus. Apakah sesuai dengan spesifikasi?

Terima kasih @milesj!

Fungsionalitas yang telah diimplementasikan telah diimplementasikan sesuai dengan spesifikasi, tetapi belum ada gambaran rinci tentang spesifikasi yang dicakup. Saya sedang berpikir untuk menambahkan itu. Namun, semua fungsionalitas dicakup oleh pengujian unit.

Tujuan awal DOM adalah untuk dapat merender sisi server komponen web dengan kinerja yang baik, seperti yang saya butuhkan untuk beberapa proyek lain.

FWIW, saya baru saja mencoba meningkatkan proyek kami dari react-scripts@3 dengan Jest 24.9, menjadi @react-scripts@4 dengan Jest 26.6.

Rangkaian uji API server kami sebelumnya telah dieksekusi dalam waktu sekitar 180-190 detik. Setelah beralih ke Jest 26.6, secara konsisten memakan waktu sekitar 220 detik. Saya bahkan mencoba memaksa resolusi minimatch ke 4.0.2 . Mengalihkan runner uji ke jest-circus tampaknya berhasil beberapa detik, tetapi secara keseluruhan, 26,6 tampaknya terasa lebih lambat.

react-scripts@4 menggunakan jest-circus secara default, fwiw. Itu juga micromatch kami gunakan, bukan minimatch . Tampaknya kami telah gagal memutar kembali micromatch melalui #10131, namun, jadi tidak mudah untuk menguji apakah itu penyebab regresi lagi

@SimenB : kami memiliki atm pengaturan migrasi yang aneh - ini adalah aplikasi MEAN / AngularJS lama yang saya konversi untuk dibuat menggunakan CRA . Konfigurasi pengujian adalah milik kami sendiri, vs konfigurasi CRA Jest bawaan - kami hanya memanfaatkan fakta bahwa CRA hadir dengan Jest sebagai ketergantungan.

Saya tidak memiliki kotak kerja di depan saya, jadi sekarang saya tidak ingat apakah yang saya maksud adalah micromatch atau apakah saya benar-benar fokus pada nama paket yang salah di sana :) Saya harus melihat melakukannya lagi minggu depan.

Saya baru menyadari bahwa v26 berjalan _a lot_ lebih lambat di iTerm daripada di terminal default macOS. Pada satu set 6500 tes saya secara konsisten mendapatkan hasil berikut:

• v24, Terminal: ~90s
• v24, iTerm2: ~90s
• v26, Terminal: ~110s
• v26, iTerm2: ~150s

Ini sedikit mengejutkan saya setelah berbulan-bulan mencoba berbagai hal untuk mengatasi perlambatan. Adakah kemungkinan orang lain dengan masalah kinerja pada mac dapat mencoba ini? Ingat, ini dengan jsdom@14 di v26.

@pleunv Saya percaya ini mungkin terkait: https://github.com/facebook/jest/pull/9294. Saya perhatikan bahwa hyperlink memperlambat iTerm2 di mesin saya, membuatnya berombak. Tetapi belum menyelidiki kecepatan eksekusi secara keseluruhan, atau menemukan orang lain yang memiliki masalah dengannya.

Eureka. Mencari "iTerm" membawa saya ke PR ini . Saya telah memperhatikan garis bawah ini sebelumnya dan tidak menyadari bahwa itu adalah hyperlink. Setelah melihat PR itu, saya menonaktifkan hyperlink di iTerm yang membuat runtime saya turun menjadi 130 detik. Setelah menerapkan kode dari PR dan menghapus hyperlink, saya kembali ke 120-an. Kewarasan sedikit pulih.

Adakah kemungkinan PR bisa dimasukkan kembali?

edit: @thymikee mengalahkan saya untuk itu

@pleunv Saya akan mencoba mencari waktu minggu ini untuk mengembalikannya. Meskipun masalah sebenarnya adalah memperbaiki ini untuk iTerm, karena terminal lain misalnya di Linux tidak memiliki masalah dengan hyperlink. Maukah Anda mengajukan masalah ke proyek iTerm?

Saya baru saja membuat perubahan ini dan itu memberi saya 1 untuk satu file pengujian. Dan urlnya masih bisa diklik, hanya saja sudah tidak digarisbawahi lagi.

Ini mungkin besar untuk lari yang lebih besar. ❤️

//edit
Lucunya tidak ada bedanya sebelumnya apakah itu iterm atau terminal. Setelah perubahan iterm lebih cepat bagi saya.

@pleunv Saya akan mencoba mencari waktu minggu ini untuk mengembalikannya. Meskipun masalah sebenarnya adalah memperbaiki ini untuk iTerm, karena terminal lain misalnya di Linux tidak memiliki masalah dengan hyperlink. Maukah Anda mengajukan masalah ke proyek iTerm?

Saya telah membuat masalah di sini (ada di GitLab). Jika ada yang memiliki detail tambahan atau proyek repro, jangan ragu untuk menambahkan.

Saya bereksperimen lagi dalam waktu yang berarti dan saya menemukan bahwa, ketika hanya menjalankannya pada subset tes yang lebih kecil (beberapa lusin file tes), hyperlink umumnya tidak membuat banyak perbedaan. Saat menjalankannya di set lengkap kami (700 file) dampaknya sangat terukur.

Saya juga mendapat kesan bahwa dalam jangka panjang keluaran konsol lelucon mulai menjadi sangat glitchy/mencolok. Garis kemajuan di bagian bawah misalnya lebih tersembunyi daripada terlihat.