<p>एक 25 प्रदर्शन है</p>

प्रतिगमन के बारे में खेद है लेकिन

क्षमा करें हमारा कोडबेस साझा नहीं कर सकता

यानी हम बिल्कुल कुछ नहीं कर सकते। यह पहली बार है जब मैंने प्रदर्शन के वापस आने के बारे में सुना है, बाकी सभी जगहों पर मैंने 10-40% _सुधार_ से 24 से 25 तक प्रदर्शन में सुना है। आपको किसी प्रकार का प्रजनन प्रदान करने की आवश्यकता है, अन्यथा हमें इस मुद्दे को बंद करना होगा। जैसा कि यह खड़ा है, यह बिल्कुल भी कार्रवाई योग्य नहीं है।

यदि आप इसे संबोधित करते हुए देखना चाहते हैं, तो आपको एक पुनरुत्पादन मामले को एक साथ रखने में कुछ समय बिताना होगा, या आशा है कि कोई और ऐसा करेगा।

ठीक है, मैं देखूंगा कि क्या मैं अपने 10 सबसे धीमे परीक्षणों को खींच सकता हूं, फिर उन्हें 24 बनाम 25 में चलाने का प्रयास करें। इस बीच, सीआई में परीक्षण चलाने से पहले कैश साफ़ करने के संबंध में आप क्या सलाह देते हैं? इसे करें? यह मत करो?

आपका कॉन्फ़िगरेशन, विशेष रूप से transforms और सेटअप फ़ाइलें शायद प्रासंगिक भी हैं

सीआई में परीक्षण चलाने से पहले कैश साफ़ करने के संबंध में आप क्या सलाह देते हैं?

मुझे व्यक्तिगत रूप से लगता है कि यह सुनिश्चित करना एक अच्छा विचार है कि झूठी नकारात्मक या सकारात्मक देने के लिए कुछ भी पुराना नहीं है। क्या यह आपके परीक्षणों के रनटाइम में _not_ कैश को साफ़ करने में बहुत बड़ा अंतर डालता है?

कैश साफ़ करने के बाद चलाने पर यह काफी धीमा प्रतीत होता है। सुझावों के लिए धन्यवाद, मैं इसे देख लूंगा और देखूंगा कि क्या मैं एक रिप्रो का प्रयास कर सकता हूं

एफडब्ल्यूआईडब्ल्यू, मैंने यह भी देखा है कि v25 या तो थोड़ा धीमा है या v24 के बराबर है। कहीं भी 10-40% के आसपास सुधार नहीं देखा है।

जैसा कि यहां बताया गया है, मैंने जेस्ट 24 पर एक महत्वपूर्ण गति देखी: https://github.com/facebook/jest/issues/7811#issuecomment -577057189

उपरोक्त का परीक्षण ओएसएक्स पर किया गया था।

हालाँकि, ठीक वही सेटअप हमारे CI पर बहुत धीमा चलता है, जो CentOS चलाता है।

लिनक्स विशिष्ट मुद्दा? कैशे फ़ाइलें लिखते समय I/O संबंधित समस्याएँ? क्या इसे रद्द करने के लिए कैश जनरेशन को पूरी तरह से बंद करना संभव है?

मुझे लगता है कि मुझे हमारे मामले में अपराधी मिल गया है, यह --collectCoverage झंडा है। जब इसे Jest 24 और 25 दोनों के लिए हटा दिया जाता है, तो हमारे परीक्षण 25 वर्ष से कम उम्र में लगभग दो गुना तेजी से चलते हैं। जब इसे सक्षम किया जाता है, तो 25 के तहत हमारे परीक्षण लगभग 4 गुना धीमे होते हैं, जो 24 वर्ष से कम उम्र के होते हैं।

यह OSX और CentOS दोनों पर प्रतिलिपि प्रस्तुत करने योग्य है, इसलिए मेरी पिछली टिप्पणी के विपरीत समस्या लिनक्स-विशिष्ट नहीं दिखाई देती है।

दिलचस्प! हमने इस्तांबुल को v3 में अपडेट किया है, हो सकता है कि वहां कुछ वापस आ गया हो। हमने v8 कोड कवरेज के लिए समर्थन जोड़ा है, इसलिए ऐसा करते समय मैंने रिफैक्टरिंग को भी गड़बड़ कर दिया होगा

हां! मैं जो देख रहा हूं उसके अनुरूप भी है। हम सीआई में कवरेज के साथ चल रहे हैं जहां यह 2x धीमा है। और जब मैं स्थानीय स्तर पर बिना covg के दौड़ता हूं तो यह काफी तेज होता है। @SimenB पुराने इस्तांबुल का उपयोग करने के लिए कोई कॉन्फ़िगरेशन विकल्प है? :)

प्रतिध्वनित करते हुए कि @csvan ने कहा कि CI में कैशे जेनरेशन को बंद करना अच्छा होगा यदि वह वास्तव में एक अपराधी है क्योंकि हम इसे वैसे भी बनाने से पहले हटा देते हैं

मैं इसे पुन: पेश करने में असमर्थ हूं - मेरे द्वारा परीक्षण किए गए रेपो का प्रदर्शन समान प्रदर्शन के साथ --coverage v24 और v25 के बीच है। क्या कोई जेस्ट 24 और जेस्ट 25 के साथ रिपोजिटरी को एक साथ रखने में सक्षम होगा जहां उनके बीच स्विच करने से अंतर दिखाई देता है?

बस हमारे सीआई बिल्ड w/कवरेज को अक्षम कर दिया, मुझे लगता है कि @csvan कुछ पर है। परीक्षण 4:00 w/कवरेज बंद बनाम 11 मिनट w/कवरेज चालू में चलाए गए। मैं यह देखने की कोशिश करूंगा कि क्या मैं इस सप्ताह के अंत में किसी बिंदु पर रेप्रो बना सकता हूं।

निर्माण एजेंट से हमारी 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)। जेस्ट 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 में अपग्रेड करने से वे त्रुटियां दूर हो जाती हैं।

मैंने यह भी देखा कि जेस्ट 25 collectCoverageFrom अलग तरह से संभालता है क्योंकि ऐसा लगता है कि यह उन फाइलों से कवरेज एकत्र करता है जिन्हें हमने उस कॉन्फ़िगरेशन में स्पष्ट रूप से अक्षम कर दिया है। क्या ग्लोब सिंटैक्स के लिए समर्थन वहां बदल गया?

कोई जेएस बिल्कुल निशान? यह देखना दिलचस्प होगा कि उसकी मौत कहां हुई।

मैंने यह भी देखा कि जेस्ट 25 कलेक्टकवरेज को अलग-अलग तरीके से हैंडल करता है क्योंकि ऐसा लगता है कि यह उन फाइलों से कवरेज एकत्र करता है जिन्हें हमने उस कॉन्फ़िगरेशन में स्पष्ट रूप से अक्षम कर दिया है। क्या ग्लोब सिंटैक्स के लिए समर्थन वहां बदल गया?

हमने माइक्रोमैच 4 में अपग्रेड किया है, हो सकता है कि इसने कुछ बदल दिया हो। हालांकि जानबूझ कर इसमें कोई बदलाव नहीं किया गया है। क्या आप पुनरुत्पादन के साथ एक अलग मुद्दा खोल सकते हैं?

कोई जेएस बिल्कुल निशान?

यह मुद्रित किया गया था:

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

संपादित करें : असल में, मुझे कवरेज अक्षम होने पर भी ढेर त्रुटियां दिखाई दे रही हैं।

हमने माइक्रोमैच 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

सीआई (ट्रैविस) के लिए समय।

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 मेरे package.json केवल jest-environment-jsdom से <24.0.0 आने से निश्चित रूप से प्रभाव पड़ा। heap out of memory त्रुटियां दूर हो गई हैं और जेस्ट बिना किसी समस्या के अपने रन पूरे करता दिख रहा है।

दिलचस्प! यदि आपके पास समय है, तो यह अच्छा होगा यदि आप परीक्षण कर सकें

• 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]
  
  
  
  • 143s परीक्षण चलाने के लिए
  
  
  • कोई बात नहीं
  
  
• [email protected]
  
  
  
  • परीक्षण चलाने के लिए 154s
  
  
  • कोई बात नहीं
  
  
• [email protected]
  
  
  
  • परीक्षण चलाने के लिए 228s
  
  
  • कई 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 

उम्मीद है की यह मदद करेगा

मुझे नहीं पता कि इससे मदद मिलेगी या नहीं, लेकिन मेरे संगठन में जेस्ट 24 से जेस्ट 25 (18 मिनट से 28 मिनट) तक काफ़ी धीमी गति से थी, जो कवरेज संग्रह (10 मिनट तक कम) को बंद करने के बाद चली गई।

@rosasynstylae जिज्ञासा से बाहर, क्या आपके कोड में बहुत सारे स्नैपशॉट परीक्षण हैं?

@benmonro यह करता है, हाँ।

तो हमारा भी! @SimenB क्या आपको लगता है कि रेपो में बहुत सारे स्नैपशॉट इसका कारण बन सकते हैं?

हमारे पास बिना स्नैपशॉट के प्रदर्शन संबंधी समस्याएं हैं। हम हालांकि कवरेज एकत्र कर रहे हैं। 24 -> 25. 2 विभिन्न परियोजनाओं से महत्वपूर्ण मंदी। यह बदलता रहता है लेकिन मंदी महत्वपूर्ण और सुसंगत है।

मैं बिना किसी बदलाव के परीक्षणों को बार-बार चला सकता हूं और परीक्षण औसतन 10 गुना धीमे हैं, फिर वे 24 के साथ थे।

मैं वापस 24 पर स्विच करता हूं और रन उसी गति से वापस आ जाते हैं जिसका हम उपयोग करते थे।

यदि आवश्यक हो तो मैं और जानकारी प्रदान कर सकता हूं। मैं बिना किसी स्नैपशॉट परीक्षण के अपनी 2 परियोजनाओं का उल्लेख करना सुनिश्चित करना चाहता था।

यहां सभी टिप्पणियों से, यह निश्चित रूप से लगता है कि कवरेज समस्या है, और शायद इस्तांबुल में एक प्रतिगमन है?

यहां सभी टिप्पणियों से, यह निश्चित रूप से लगता है कि कवरेज समस्या है, और शायद इस्तांबुल में एक प्रतिगमन है?

मैं इस्तांबुल पर उंगली उठाने की इतनी जल्दी नहीं करूंगा। मेरे मामले में, कवरेज अक्षम होने पर भी, मुझे जेस्ट 25 में महत्वपूर्ण प्रदर्शन और स्थिरता के मुद्दे दिखाई दे रहे हैं। देखें https://github.com/facebook/jest/issues/9457#issuecomment -579423330

यह संभव है कि दो अलग-अलग मुद्दे हों:

1) मज़ाक-वातावरण-jsdom-चौदह, और . के साथ मुद्दे
2) इस्तांबुल कवरेज के मुद्दे

मैंने micromatch से ^3.0.0 डाउनग्रेड किया और --coverage का उपयोग करते हुए एक बड़े पैमाने पर गति देखी, कमोबेश उस प्रदर्शन पर वापस आ गया जो हमने जेस्ट 24 के तहत देखा था। क्या कोई पुन: पेश कर सकता है?

अद्यतन: हालांकि, अब --coverage बिना चल रहा है, प्रदर्शन के जेस्ट 24 स्तरों पर भी वापस आ गया है - दो बार धीमा: - /

@EvHaus जाँच के लिए धन्यवाद, बहुत दिलचस्प! दुर्भाग्य से, मैं अभी भी इसे पुन: पेश करने में असमर्थ हूं। तो एक प्रजनन अभी भी भयानक होगा, इस तरह मैं इसे डीबग करने का प्रयास कर सकता हूं।

मैंने micromatch से ^3.0.0 डाउनग्रेड किया और --coverage का उपयोग करते हुए एक बड़े पैमाने पर गति देखी, कमोबेश उस प्रदर्शन पर वापस आ गया जो हमने जेस्ट 24 के तहत देखा था। क्या कोई पुन: पेश कर सकता है?

अद्यतन: हालांकि, अब --coverage बिना चल रहा है, प्रदर्शन के जेस्ट 24 स्तरों पर भी वापस आ गया है - दो बार धीमा: - /

दुनिया में क्या... जहां तक ​​मैं इस्तांबुल में कुछ भी नहीं देख सकता माइक्रोमैच पर निर्भर करता है, तो यह कवरेज को प्रभावित क्यों करना चाहिए यह मेरे से परे है

पूरे माइक्रोमैच प्रदर्शन की बात थोड़ी बेतुकी हो रही है, कवरेज के साथ v3 v4 से तेज है, बिना v4 v3 से तेज है? मैं

@SimenB हाँ, इसे हमारे CI के माध्यम से भी केवल पुष्टि करने के लिए चलाया। जोड़ने के अलावा कुछ नहीं बदलना

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

--coverage का उपयोग करते समय हमारे package.json ने रन से 6 मिनट की दूरी पर एक ठोस मुंडन किया, इसे मोटे तौर पर Jest 24 के तहत हमने जो देखा, उसे वापस लाया।

जहाँ तक मैं इस्तांबुल में कुछ भी नहीं देख सकता माइक्रोमैच पर निर्भर करता है

यह टिप्पणी किसी अन्य सूत्र में मिली जो इससे संबंधित हो सकती है:

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

इस्तांबुल में micromatch में कुछ भी पुष्टि नहीं की गई है (वे बेबेल प्लगइन में minimatch का उपयोग करते हैं)।

यह बहिष्करणों के ठीक से काम न करने के बारे में कुछ हो सकता है, निश्चित रूप से। हम इसका उपयोग यह जांचने के लिए करते हैं कि हमें क्या उपकरण चाहिए: https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/ shouldInstrument.ts। क्या आप शायद वहां कुछ लॉग इन कर सकते हैं और देख सकते हैं कि क्या हम true साथ कहीं भी micromatch@4 लौटाते हैं जो हम micromatch@3 लिए नहीं करते हैं?

निश्चित रूप से 2 अलग-अलग मुद्दों की तरह लगता है, एक jsdom के बारे में और दूसरा कवरेज के बारे में

मैं पुष्टि कर सकता हूं कि सीआई में हमारे लिए यह सामान्य गति पर वापस आ गया है जब हम माइक्रोमैच @ 3 को भी हल करते हैं।

जेस्ट + टाइपस्क्रिप्ट + प्रतिक्रिया कोडबेस यहाँ। इस मुद्दे को देखकर और माइक्रोमैच ^3.0.0 को बाध्य करने के लिए npm-force-resolutions का उपयोग करना पागल मंदी को ठीक करने के लिए लग रहा था।

क्या आपके कॉन्फ़िगरेशन में कस्टम परीक्षण फ़ाइल पैटर्न पीआर कवरेज पैटर्न हैं?

@EvHaus मुझे इसमें बहुत दिलचस्पी है यदि आप

अगर आपका यही मतलब है, तो हाँ।

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

हमारे पास वह भी है और हमारा लंबाई/मानों में काफी समान दिखता है

@ प्राचीन123 हाँ, बिल्कुल। नकारात्मक पैटर्न के लिए माइक्रोमैच रिग्रेशन से संबंधित लगता है। धन्यवाद!

नकारात्मक पैटर्न के लिए माइक्रोमैच रिग्रेशन से संबंधित लगता है। धन्यवाद!

नोट किया गया, मैं इसे ASAP में देख लूंगा।

संपूर्ण माइक्रोमैच प्रदर्शन की बात थोड़ी बेतुकी हो रही है

प्रदर्शन में गिरावट के लिए खेद है। ग्लोबिंग के लिए रेगुलर एक्सप्रेशन बनाना जितना दिखता है, उससे कहीं अधिक कठिन है। खासतौर पर तब जब उसे नकार से निपटने और क्रॉस-प्लेटफॉर्म होने की जरूरत हो। मैं अब इस पर गौर कर रहा हूं।

@jonschlinkert इसका मतलब बिल्कुल भी आरोप लगाने वाला नहीं था, जो काम आप माइक्रोमैच और संबंधित पुस्तकालयों में डाल रहे हैं, उसकी बहुत सराहना की जाती है! :दिल:

हां! @SimenB ने क्या कहा। ❤️ . के अलावा कुछ नहीं

@EvHaus मुझे इसमें बहुत दिलचस्पी है यदि आप

मेरे package.json मैंने सेट किया है:

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

npm install फिर से चलाया गया, और फिर मैन्युअल रूप से node_modules/jest/micromatch (जो संस्करण 4 पर था) को हटा दिया गया। फिर मेरे परीक्षण फिर से चलाए।

दुर्भाग्य से, मैं अभी भी कई "जावास्क्रिप्ट हीप आउट ऑफ़ मेमोरी" त्रुटियाँ देख रहा हूँ।

क्या मैं डाउनग्रेड सही ढंग से कर रहा हूँ?

resolutions जरूरत है yarn , npm ने इसे अभी तक लागू नहीं किया है (यह v7 के रोडमैप पर है: https://blog.npmjs.org/post/186983646370/npm- क्ली-रोडमैप-समर-2019)

@EvHaus npm v7 के बाहर आने तक आप https://www.npmjs.com/package/npm-force-resolutions

विलंब के लिए क्षमा चाहते हैं। micromatch को v3 में लॉक करने के लिए npm-force-resolutions (जो सही काम कर रहा है) का उपयोग किया। दुर्भाग्य से, इसने मेरी ढेर त्रुटियों को दूर नहीं किया।

तो मेरे लिए, यह अभी भी [email protected] को दोष देना है, जैसा कि यहां बताया गया है: https://github.com/facebook/jest/issues/9457#issuecomment -579423330

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 का उपयोग करने से अधिक (जो कि डिफ़ॉल्ट रूप से जेस्ट के साथ जहाज है) और कोई अन्य परिवर्तन नहीं? क्या आप 16.1.0 के साथ भी परीक्षण कर सकते हैं (हालांकि यह स्मृति को लीक करता है, इसलिए परीक्षण करना कठिन हो सकता है)। JSDOM बस कस्टम तत्व समर्थन के साथ उतरा, वहाँ _might_ कुछ प्रतिगमन हो सकता है? पक्का नहीं

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% ish तक सुधार करता प्रतीत होता है

हाय @ सिमेनबी ,

मैंने यहां प्रतिलिपि प्रस्तुत करने योग्य मामला बनाया है https://github.com/olebedev/jest-perf-issue । कृपया देख लीजिये। तुलना करने के लिए परिणाम के नीचे। /सीसी @joscha

परिणाम

बेंचमार्क MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz पर चलाए गए थे।

| मज़ाक संस्करण | शाखा | समय |
|:--------------|:------:|----------:|
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

हमारे मामले में, जहां जेस्ट v25.1 v24.9 की तुलना में ~ 50% धीमा था, अब नवीनतम जेस्ट v25.2.0 v25.1 की तुलना में और भी 20% धीमा है।

@olebedev वाह , यह दर्दनाक है

मुझे आपके समान नंबर मिल रहे हैं। यदि यह एक वास्तविक परियोजना पर आधारित है तो मैं v8 कवरेज का उपयोग करने की सलाह देता हूं। यह आपके प्रजनन में मेरी मशीन पर 600 से 35 तक रनटाइम लेता है। विशाल अंतर का कारण शायद यह है कि हम v8 कवरेज के साथ गैर-कवर की गई फ़ाइलों को साधने की कोशिश नहीं करते हैं (हम बस कहते हैं कि हर बाइट खुला है, जो v8 के साथ काम करता है)।

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

निश्चित नहीं है कि यह इतना धीमा क्यों है... मैं इस पर गौर करने के लिए कुछ समय निकालने की कोशिश करूंगा (हालांकि जल्द ही कभी भी नहीं होगा)। यह कम से कम v25 पर v24 . की तुलना में धीमा नहीं होना चाहिए

क्या मैं दस्तावेज़ों को सही ढंग से समझता हूं कि हम एक साथ v8 कवरेज का उपयोग कर सकते हैं
...-sixteen पर्यावरण के साथ?

चीयर्स,
जे

बुधवार, 8 अप्रैल 2020, 22:33 को सिमेन बेक्खुस, नोटिफिकेशन @github.com ने लिखा:

@olebedev https://github.com/olebedev वाह , यह दर्दनाक है

मुझे आपके समान नंबर मिल रहे हैं। यदि यह एक वास्तविक परियोजना I . पर आधारित है
v8 कवरेज का उपयोग करने की सलाह देते हैं। यह my . पर रनटाइम को 600s से 35s तक लेता है
आपके प्रजनन में मशीन। विशाल अंतर का कारण शायद यह है कि
हम 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 । यह भी ध्यान दें कि यह केवल नोड 10+ पर समर्थित है, नोड 8 पर नहीं।

(मैंने कभी केवल नोड एनवी के साथ इसका परीक्षण किया है, लेकिन अगर यह जेएसडॉम एनवी के साथ काम नहीं करता है तो यह एक बग है - कृपया एक अलग मुद्दा खोलें 🙂)

jest-environment-jsdom-sixteen + v8 कवरेज प्रदाता के रूप में हमारे लिए jest 25.3.0, नोड 12.16 पर लगभग 20% खराब था। हम यह भी डिबग करने की कोशिश कर रहे हैं कि हमारा परीक्षण प्रदर्शन जेस्ट 24 से 25 तक जाने पर लगभग 80% खराब क्यों हो गया।

@joual क्या आपने

यहां एक समान अनुभव होने पर, परीक्षण समय (_बिना_कवरेज) v25 पर दोगुना होकर 35-40 सेकंड से 80-90 और कभी-कभी अधिक हो जाता है। v3 पर माइक्रोमैच लॉक करने का प्रयास किया, कोई मापने योग्य अंतर नहीं। Fwiw, हमारे पास लगभग 3k परीक्षण हैं जिनमें से 58 स्नैपशॉट परीक्षण हैं।
Jsdom को डाउनग्रेड करने का प्रयास किया गया, लेकिन ऐसा लगता है कि हाल ही में हमारे द्वारा उपयोग की जा रही सुविधाओं के कारण बहुत सारे परीक्षण टूटना शुरू हो गए हैं। मैं देखूंगा कि क्या मैं इसे किसी भी तरह से प्राप्त कर सकता हूं और वापस रिपोर्ट कर सकता हूं।

@SimenB प्रीटियर प्रोजेक्ट पर कवरेज कलेक्ट जॉब भी बहुत धीमी है, क्या आप इसे चेक कर सकते हैं? https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest कवरेज एकत्र करता है, अन्य काम नहीं।

यहां एक समान अनुभव होने पर, परीक्षण समय (_बिना_कवरेज) v25 पर दोगुना होकर 35-40 सेकंड से 80-90 और कभी-कभी अधिक हो जाता है। v3 पर माइक्रोमैच लॉक करने का प्रयास किया, कोई मापने योग्य अंतर नहीं। Fwiw, हमारे पास लगभग 3k परीक्षण हैं जिनमें से 58 स्नैपशॉट परीक्षण हैं।
Jsdom को डाउनग्रेड करने का प्रयास किया गया, लेकिन ऐसा लगता है कि हाल ही में हमारे द्वारा उपयोग की जा रही सुविधाओं के कारण बहुत सारे परीक्षण टूटना शुरू हो गए हैं। मैं देखूंगा कि क्या मैं इसे किसी भी तरह से प्राप्त कर सकता हूं और वापस रिपोर्ट कर सकता हूं।

आज jest@24 पर विभिन्न jsdom संस्करणों के साथ प्रयोग कर रहा था (जो कि डिफ़ॉल्ट रूप से v11 है)। V14 तक सब कुछ ठीक काम करता प्रतीत होता है, लेकिन v15 टेस्ट रन के रूप में लगातार 50-60% अधिक समय लगता है। v16 में वही कहानी। मैं देखूंगा कि क्या मैं jsdom को v14 में डाउनग्रेड करके jest@25 पर समान परफ प्राप्त कर सकता हूं।

[email protected] में कुछ मेमोरी सुधार हैं, @EvHaus क्या आप इसे --detect-leaks पिछले संस्करणों में लीक का पता लगाता है, लेकिन 16.2.2 को नहीं।

यदि आपके पास बहुत सारे सिम्लिंक हैं (जो विंडोज़ पर सुपर स्लो है), तो मैंने कुछ अन्य सुधार भी किए हैं, इसलिए यदि लोग [email protected] को आज़मा सकते हैं तो यह बहुत अच्छा होगा

@SimenB इसका परीक्षण करने का सबसे आसान तरीका क्या है? अगर मैं [email protected] सीधे एक डिपेंडेंसी जेस्ट के रूप में जोड़ता हूं तो इसे अनदेखा करता है और jest-environment-jsdom साथ जो कुछ भी बंडल किया जाता है उसका उपयोग करता है जो आज 15.2.1 है।

मैं यह सुनिश्चित करने के लिए npm कैसे छल कर सकता हूं कि यह मेरे इच्छित jsdom संस्करण का उपयोग कर रहा है?

jest-environment-jsdom-sixteen इंस्टॉल करें और इसका इस्तेमाल करें https://jestjs.io/docs/en/configuration#testenvironment -string

अल्फा प्रकाशित, इसलिए आप jest@next आज़मा सकते हैं - यह jsdom 16 आउट ऑफ़ द बॉक्स के साथ आता है

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

बहुत बुरा क्या यह कवरेज के साथ या बिना कवरेज के है?

वह कवरेज के बिना था। स्पष्ट करना चाहिए था।

क्या आपको लगता है कि मैं नोड का काफी पुराना संस्करण चला रहा हूं (v10) इसमें कारक होगा?

आप नए संस्करणों का उपयोग करने का प्रयास कर सकते हैं, यदि और कुछ नहीं तो यह एक दिलचस्प डेटा बिंदु होगा। कोशिश करने के लिए अन्य चीजें मरने से ठीक पहले ढेर डंप बनाने की कोशिश करना है। ढेर पर क्या है?

यह दिलचस्प है कि किसी ने भी उल्लेख नहीं किया कि माइक्रोमैच@4 अब रेगेक्सप्स को कैश नहीं करता है (देखें https://github.com/micromatch/micromatch/pull/151 और https://github.com/facebook/jest/pull/10131 लापता का परिचय देता है मज़ाक पक्ष पर कैशिंग।

मेरे लिए micromatch@3 में डाउनग्रेड करें और jest-environment-jsdom-sixteen अपग्रेड करें जिससे 50% समय की बचत हुई।
लेकिन जेस्ट 26 और बिल्ट-इन jsdom के साथ मुझे अभी भी लीक त्रुटि मिल रही है जब मेरे मामले में --detectLeaks के साथ जेस्ट चलाया जाता है। ताजा रेपो की कोशिश की और सभी अच्छी तरह से काम करते हैं।

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 मिनट से अधिक समय लगता है। मैं वास्तव में पुनरुत्पादन के लिए इस मुद्दे को अलग नहीं कर सकता, लेकिन अगर आप मुझे कुछ सलाह देते हैं कि क्या परीक्षण करना है, तो मुझे बहुत दिलचस्पी होगी। आपने उसमें जो भी काम किया उसके लिए धन्यवाद!

@ सिमेनबी

prettier प्रोजेक्ट के लिए, कवरेज एकत्र करते समय अभी भी v24 से धीमा है।

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

मैं पुष्टि कर सकता हूं कि बिटबकेट पाइपलाइन पर संस्करण 25 और 26 प्रदर्शन 24 से कम हैं। मैंने यह भी देखा है कि कवरेज सक्षम होने से सुस्ती बढ़ जाती है। संस्करण 25 26 की तुलना में और भी खराब हो जाता है और मेमोरी खपत के कारण पाइपलाइन क्रैश हो जाती है।

@SimenB मैंने यह पता लगाने के लिए git bisect किया कि 24.9 और 25.1 के बीच प्रदर्शन प्रतिगमन कहाँ पेश किया गया था। मैंने सुंदर परीक्षणों का उपयोग किया क्योंकि वे 24.9 से 26.1 तक सभी तरह से संशोधन के बिना चलते हैं।

मैंने अक्षम कैश के साथ जेएस सबसेट (कुछ समय सुरक्षित करने के लिए) के तीन रनों के संचित रनटाइम की तुलना की। अधिक विशेष रूप से मेरे द्वारा उपयोग की जाने वाली कमांड ( yarn run jest --no-cache tests/js/ ) नोड 10.19.5 के साथ थी। क्योंकि नोड 10 24.9 के लिए अनुशंसित संस्करण था।

परिणाम:

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

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

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

चूंकि compileFunction को परिभाषित नहीं किया गया है तो एक फॉलबैक है, 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 के रनटाइम पर वापस आ जाता है। मुझे यकीन है कि यह समाधान नहीं है, लेकिन कम से कम हमारे पास काम करने के लिए कुछ है।

एक अन्य डेटा बिंदु के रूप में, हमारे जेस्ट सूट में वर्तमान में [email protected] के साथ लगभग 2767 सेकंड हमारे अपडेट MR में लगभग 3497 सेकंड लगते हैं, लगभग 27% की वृद्धि।

सभी महान कार्यों के लिए धन्यवाद, जेस्ट टीम, मुझे आशा है कि @wurstbonbon के जासूसी कौशल आपको उस प्रतिगमन को ठीक करने में मदद कर सकते हैं!

@wurstbonbon खुदाई के लिए समय निकालने के लिए धन्यवाद! बहुत दिलचस्प है कि compileFunction धीमा है... इसका मतलब यह होना चाहिए कि आप पैच लगाने के बजाय केवल एक कस्टम परीक्षण वातावरण का उपयोग कर सकते हैं।

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(और jsdom env के लिए भी यही)। क्या आप पुष्टि कर सकते हैं?

यह एक ऐसी अड़चन है, हालांकि अजीब लगता है - नोड ने 18 महीने पहले इसका उपयोग करने के लिए स्विच किया था: https://github.com/nodejs/node/pull/21573। तो शायद यह कुछ अजीब है जो हम अपनी तरफ से कर रहे हैं। लिंक किया गया https://github.com/nodejs/node/issues/26229 हालांकि बहुत दिलचस्प है - शायद हमें अपनी तरफ से कुछ और कैशिंग करने की आवश्यकता है?

@ सिमेनबी मैंने बस उस कस्टम एनवी के समान कुछ करने की कोशिश की और ऐसा लगता है कि यह थोड़ा बेहतर था (लेकिन अभी भी जेस्ट 24 से धीमा)।

मुझे MyNodeEnv.prototype.getVmContext = null; , हालांकि, क्योंकि मैं जेस्ट 26 के साथ परीक्षण कर रहा हूं, और ऐसा लगता है कि यह if (typeof this._environment.getVmContext === 'function') { अभी जांचता है। सुनिश्चित नहीं है कि यह अन्य मुद्दों का कारण बन सकता है, यद्यपि।

कुछ रनों के बाद मैं ये परिणाम देख रहा हूं:

जेस्ट 26 w/testEnvironment: "नोड" => ~280s
जेस्ट 26 w/कस्टम परीक्षण वातावरण => ~210s
जेस्ट 24 => ~160s

मुझे बताएं कि क्या मैं किसी अन्य जानकारी या कुछ और में मदद कर सकता हूं!

जैसा कि अपेक्षित था कस्टम एनवी का परिणाम प्रीटियर के लिए समान गति में होता है।

मैंने इसे अपने कोडबेस पर भी आजमाया है जहां अंतर ~ 270 बनाम ~ 200 है, इसलिए केवल 25% और 40% की कमी नहीं है। दुर्भाग्य से मैं अपने परीक्षण को जेस्ट 24 के साथ नहीं चला सकता क्योंकि हम नए आधुनिक टाइमर का मज़ाक उड़ाते हुए भरोसा करते हैं।

मुझे उपरोक्त मेरे उदाहरण में delete याद आया, इसके लिए खेद है।

मुझे आश्चर्य है कि संकलित कार्यों को मैन्युअल रूप से कैश करने के लिए पर्याप्त है - क्या आप इस पैच को लागू करने का प्रयास कर सकते हैं? (दोनों ट्रांसपिल्ड जेएस और टीएस स्रोत यहां शामिल हैं)

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

हालांकि इसने प्रदर्शन में थोड़ा सुधार किया, यह अभी भी जेस्ट 24.x की तुलना में काफी धीमा है:

• जेस्ट 24.x: 2580 सेकंड हमारे जेस्ट परीक्षणों का कुल रनटाइम
• जेस्ट 26.एक्स: 3166 सेकंड हमारे जेस्ट परीक्षणों का कुल रनटाइम

@leipert क्या आपने किसी भी तरह से jsdom पर्यावरण को 14 में डाउनग्रेड करने का प्रयास किया है?

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" आपके जेस्ट कॉन्फिगर में। यह अभी भी हमारे लिए अवधि वृद्धि के बड़े हिस्से के लिए जिम्मेदार प्रतीत होता है (40-50% जोड़ता है), लेकिन ऐसा लगने लगा है कि खेल में कई प्रतिगमन हैं।

@pleunv jest jest-environment-jsdom-sixteen साथ jsdom 16 पर हैं, हमें वेब घटकों के परीक्षण के साथ कुछ मुद्दों के कारण अपग्रेड करना पड़ा। इसलिए हम केवल एक ही बदलाव करते हैं: 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 अभी भी खुले हैं।

वास्तव में नहीं, अधिकांश पुस्तकालय इसका उपयोग करते हैं। उदाहरण के लिए मिनिमैच देख सकता है, लेकिन मुझे संदेह है कि यह व्यवहार्य होगा

@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
मज़ाक 26 पैच | 3:32 | 4:36 | 3:48 | 0:53
मज़ाक 26 अप्रकाशित | 5:10 | 6:12 | 5:11 | 1:07
26 पैच बनाम 24 | 4% | 31% | 9% | 1%
26 अप्रकाशित बनाम 24 | 52% | 76% | 49% | 27%
26 पैच बनाम अनपैच्ड | 46% | 35% | 36% | 25%

अभी भी दिलचस्प है कि v26 अभी भी v24 पर सुधार नहीं करता है ...

धन्यवाद @ सेल्यूल! यह मेरे लिए काफी अच्छा है - जब मेरे पास कुछ समय होगा तो मैं एक पीआर एक साथ रखूंगा

अद्भुत सामान! यह केवल माइक्रोमैच मुद्दा छोड़ देता है, उम्मीद है कि रेपो फिर से सक्रिय रखरखाव के तहत आएगा।

बीटीडब्लू, जेएसडीओएम में मुझे लगता है कि परफ रिग्रेशन भी है। जैसा कि मैंने एक बड़े वेब प्रोजेक्ट पर ऐसे परीक्षण किए। ऊपर वर्णित कोई पैच लागू नहीं किया जाता है।
और ऐसा लग रहा था।

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
शीत: 149s

जेस्ट 26.4
शीत: 226s

अच्छी खबर 🙂 मुझे लगता है कि हम केवल माइक्रोमैच रिग्रेशन पर वापस आ गए हैं, फिर

यदि आप लोग npm-force-resolutions का उपयोग जबरदस्ती माइक्रोमैच 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] अपडेट करने के बाद यह हमें ट्रैविस पर चलने के समय का 20% बचाता है

हमारे परिणाम:

यह v26.5 . है

• 323.98s
• 321.24s

यह वी24.9 . है

• 262.17s
• 275.96s

धन्यवाद @ सिमेनबी! ये अद्भुत है। ~2000 सुइट्स में हमारे ~22000 परीक्षणों के लिए हमारे परिणाम:

• जेस्ट 24.x: 2864 सेकंड
• जेस्ट 26.5.2: 2967 एस

जो लगभग 3% धीमा है और इस प्रकार त्रुटि के मार्जिन में, ~ 27% मंदी की तुलना में हमने पहले देखा था। धन्यवाद, अब हमें बस मर्ज करने की जरूरत है: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

बस यह नोट करना चाहता था कि मेरे पास पहले जो "मेमोरी से बाहर ढेर" मुद्दे थे, वे जेस्ट 26.5.2 और नोड 14 (पहले नोड 10 पर थे) में अपग्रेड करने के बाद चले गए हैं। सुनिश्चित नहीं है कि जेस्ट बनाम नोड द्वारा कितनी समस्या हुई थी, लेकिन यदि अन्य समान समस्याएं देख रहे हैं तो दोनों को अपग्रेड करने का प्रयास करें।

अद्यतन : कोई बात नहीं। मुझे ओओएम त्रुटियां फिर से मिलनी शुरू हो गई हैं। मुझे लगता है कि यह सीमा रेखा पर है कि मेरा लैपटॉप क्या संभाल सकता है और पहले कुछ रन अच्छे थे, लेकिन अब यह फिर से मर रहा है। अभी भी 24.xx से चिपके रहना होगा :(

अगर कोई दिलचस्पी लेता है, तो मैंने एक डोम बनाया है जिसमें जेएसडीओएम की तुलना में बहुत अच्छा प्रदर्शन है। इसमें जेस्ट का समर्थन है।

| ऑपरेशन | जेएसडीओएम | हैप्पी डोम |
| ---------------------------------------- | ------- | ------------- |
| आयात / आवश्यकता | 333 एमएस | 45 एमएस |
| पार्स एचटीएमएल | 256 एमएस | 26 एमएस |
| एचटीएमएल को क्रमबद्ध करें | 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/

@ मकर 86 अच्छा लग रहा है। क्या यह विशिष्ट अनुरूप है?

@ मकर 86 अच्छा लग रहा है। क्या यह विशिष्ट अनुरूप है?

धन्यवाद @milesj!

कार्यान्वित की गई कार्यक्षमता को चश्मे के अनुसार लागू किया गया है, लेकिन अभी तक कौन से स्पेक्स को कवर किया गया है, इसका कोई विस्तृत अवलोकन नहीं है। मैं इसे जोड़ने के बारे में सोच रहा हूं। हालांकि, सभी कार्यक्षमता यूनिट परीक्षणों द्वारा कवर की जाती है।

डीओएम का प्रारंभिक लक्ष्य वेब घटक सर्वर पक्ष को अच्छे प्रदर्शन के साथ प्रस्तुत करने में सक्षम होना था, क्योंकि मुझे कुछ अन्य परियोजनाओं के लिए इसकी आवश्यकता थी।

Fwiw, मैं बस से हमारी परियोजना जोड़ने से करने की कोशिश की react-scripts@3 जेस्ट 24.9 के साथ करने के लिए @react-scripts@4 जेस्ट 26.6 के साथ।

हमारा सर्वर एपीआई परीक्षण सूट पहले लगभग 180-190 सेकंड में निष्पादित हो रहा था। जेस्ट 26.6 पर स्विच करने के बाद, यह लगातार लगभग 220 सेकंड ले रहा था। मैंने minimatch से 4.0.2 संकल्प को मजबूर करने का भी प्रयास किया। टेस्ट रनर को jest-circus स्विच करना कुछ सेकंड के लिए दस्तक देना प्रतीत होता है, लेकिन कुल मिलाकर, 26.6 काफ़ी धीमा लगता है।

react-scripts@4 डिफ़ॉल्ट रूप से jest-circus का उपयोग करता है, fwiw। यह micromatch हम उपयोग करते हैं, न कि minimatch । ऐसा लगता है कि हमने micromatch माध्यम से #10131 के माध्यम से रोलिंग बैक तोड़ दिया है, हालांकि, यह परीक्षण करना इतना आसान नहीं है कि यह अब प्रतिगमन का कारण है या नहीं

@SimenB : हमारे पास एक अजीब माइग्रेशन सेटअप एटीएम है - यह एक विरासत MEAN/AngularJS ऐप है जिसे मैंने CRA का उपयोग करके बनाने के लिए परिवर्तित किया है । परीक्षण कॉन्‍फ़िगर हमारा अपना है, बनाम बिल्ट-इन CRA Jest कॉन्‍फ़िगरेशन - हम केवल इस तथ्‍य का लाभ उठा रहे हैं कि CRA जेस्ट के साथ एक डिपेंडेंसी के रूप में आता है।

मेरे पास एटीएम के सामने मेरा वर्क बॉक्स नहीं है, इसलिए अब मुझे याद नहीं है कि क्या मेरा मतलब वास्तव में micromatch या अगर मैंने वास्तव में गलत पैकेज नाम पर ध्यान केंद्रित किया :) मुझे देखना होगा अगले हफ्ते फिर से उस पर।

मैंने अभी देखा कि v26 macOS के डिफ़ॉल्ट टर्मिनल की तुलना में iTerm में _alot_ धीमी गति से चलता है। 6500 परीक्षणों के एक सेट पर मुझे लगातार निम्नलिखित परिणाम मिलते हैं:

• v24, टर्मिनल: ~90s
• v24, iTerm2: ~90s
• v26, टर्मिनल: ~ 110s
• v26, iTerm2: ~150s

मंदी को हल करने के लिए विभिन्न चीजों की कोशिश करने के महीनों के बाद इसने मेरे दिमाग को थोड़ा उड़ा दिया। मैक पर पूर्ण मुद्दों के साथ कोई और मौका किसी और को यह कोशिश कर सकता है? ध्यान रहे, यह v26 पर jsdom@14 के साथ है।

@pleunv मेरा मानना ​​है कि यह संबंधित हो सकता है: https://github.com/facebook/jest/pull/9294 । मैंने देखा कि हाइपरलिंक मेरी मशीन पर iTerm2 को धीमा कर देता है, जिससे यह अस्थिर हो जाता है। लेकिन निष्पादन की समग्र गति की जांच नहीं की है, और न ही किसी अन्य व्यक्ति को इसके साथ समस्या थी।

यूरेका। "आईटर्म" की खोज ने मुझे इस जनसंपर्क में लाया। मैंने इन अंडरलाइन्स को पहले देखा था और मुझे नहीं पता था कि ये हाइपरलिंक्स हैं। उस पीआर को देखने के बाद मैंने आईटर्म में हाइपरलिंक्स को निष्क्रिय कर दिया जिससे मेरा रनटाइम 130 से नीचे आ गया। पीआर से कोड लागू करने और हाइपरलिंक्स को हटाने के बाद मैं 120 के दशक में वापस आ गया हूं। विवेक थोड़ा बहाल।

कोई मौका है कि पीआर वापस आ सकता है?

संपादित करें: @thymikee ने मुझे इसके लिए हराया

@pleunv मैं इसे वापस लाने के लिए इस सप्ताह कुछ समय

मैंने अभी यह परिवर्तन किया है और इसने मुझे एकल परीक्षण फ़ाइल के लिए 1s दिया है। और आप अभी भी यूआरएल पर क्लिक कर सकते हैं, यह अब रेखांकित नहीं है।

यह बड़े रनों के लिए बहुत बड़ा हो सकता है। ❤️

// संपादित करें
मजेदार बात यह है कि इससे पहले कोई फर्क नहीं पड़ता था कि यह इटरम या टर्मिनल था। परिवर्तन के बाद मेरे लिए आईटर्म तेज है।

@pleunv मैं इसे वापस लाने के लिए इस सप्ताह कुछ समय

मैंने यहां एक मुद्दा बनाया

मैं इस बीच कुछ और प्रयोग कर रहा था और मैंने पाया कि, जब इसे केवल परीक्षणों के एक छोटे उपसमुच्चय (दो दर्जन परीक्षण फाइलों) पर चलाया जाता है, तो हाइपरलिंक्स आम तौर पर इतना अंतर नहीं करते हैं। हालांकि इसे हमारे पूरे सेट पर चलाते समय (700 फाइलें) प्रभाव बहुत अधिक मापने योग्य होता है।

मुझे यह भी आभास है कि लंबे समय तक जेस्ट का कंसोल आउटपुट वास्तव में गड़बड़/चमकदार होने लगता है। उदाहरण के लिए तल पर प्रगति रेखाएं दृश्यमान से अधिक छिपी हुई हैं।