Jest: Jest सभी विंडोज़ मशीनों (Windows 10 और उससे कम) पर 3x धीमा है

संबंधित: # 6783

क्या यह धीमी गति से शुरू हो रहा है, या घड़ी मोड में भी है? यदि स्टार्टअप के दौरान, आप watchman स्थापित करने का प्रयास कर सकते हैं, तो इसमें मदद करनी चाहिए (https://facebook.github.io/watchman/docs/install.html)

जब परीक्षणों के माध्यम से जा रहा है तो यह वहां से ठीक लग रहा है (EDIT: वास्तव में यह धीमी गति से परीक्षण के रूप में अच्छी तरह से चल रहा है। यह 0.5 सेकंड की गति से एक-एक करके गुजरता है, जबकि मानक 0.05 की तरह लगता है।
प्रति परीक्षण सेकंड)
हालाँकि, यह शुरू होने और / या जेस्ट परीक्षण शुरू करने पर धीमा है (लगभग 4-6 सेकंड की देरी, मैक मशीनों की तुलना में 4-6x धीमा)

मैं पहरेदार की कोशिश करूंगा और आपको वापस मिलूंगा

यदि आप स्टार्टअप जैसे ndb का उपयोग करके प्रोफ़ाइल कर सकते हैं और यह पता लगा सकते हैं कि धीमा क्या है, तो यह एक बड़ी मदद होगी eg

चौकीदार स्थापित होने के साथ देरी अभी भी धीमी है।
मैंने ndb "jest --verbose" चलाने के साथ एक रूपरेखा परीक्षण किया है, यहाँ परिणाम हैं:

पहले 1.7 सेकंड का स्क्रीनशॉट:

1.8 सेकंड के 2.7 सेकंड के स्क्रीनशॉट

रिकॉर्डिंग के बाद ndb में प्रोफाइल टैब से .json फ़ाइल और .heapsnapshot फ़ाइल सहेजी गई:

profiling.zip

@pfftdammitchris क्या है आपका [सटीक] usecase जहाँ आपने धीमी गति से देखा है?
(एक फ़ाइल या कई फाइलें)? (घड़ी मोड या नहीं)? क्या आप छूट प्रदान कर सकते हैं।
एक फ़ाइल वॉच मोड समस्या के लिए => कृपया मेरी अंतिम टिप्पणी को इसमें पढ़ें: # 6783

यह वॉच मोड के साथ या बिना सिंगल और मल्टीपल दोनों फाइलों के लिए धीमा है। बहुत बार हर बार यह किसी भी परीक्षा को चलाता है, परीक्षणों को शुरू करने पर 3+ सेकंड की देरी होती है, और यह धीमी गति से एक-एक करके 0.3 या 0.4 या 0.5 सेकंड तक परीक्षण चला रहा है, जबकि अन्य परीक्षण धावक जैसे मोचा / ची आमतौर पर बस चलेगा प्रत्येक ऐसा लगता है जैसे कि प्रत्येक 0.05 सेकंड।

मैं कोडेंडबॉक्स में जेस्ट का उपयोग करता हूं और वे इनिशियलाइज़ेशन / रनिंग टेस्ट पर तुरंत जेस्ट चलाते हैं, मैंने देखा कि मेरे सहकर्मी अपने मैक मशीनों पर जेस्ट चलाते हैं और वे इसे सामान्य रूप से तुरंत चलाते हैं। जहाँ तक मुझे पता है यह सिर्फ विंडोज़ मशीन है। मैं काम पर एक विंडोज़ मशीन का उपयोग करता हूं और वहां पर धीमी गति से समस्या हो रही है, और मैं घर पर भी एक विंडोज़ मशीन का उपयोग करता हूं और समस्या यहां जारी है।

मैंने --runInBand का उपयोग किया, लेकिन ऐसा लग रहा था कि भावना के आधार पर, प्रत्येक अतिरिक्त 0.2 सेकंड से इकाई परीक्षणों को थोड़ा धीमा कर दिया है।

स्पष्टीकरण

मैंने --runInBand का उपयोग किया, लेकिन ऐसा लग रहा था कि भावना के आधार पर, प्रत्येक अतिरिक्त 0.2 सेकंड से इकाई परीक्षणों को थोड़ा धीमा कर दिया है।

=> क्या आपने v24 के साथ प्रयास किया? v23 से v24 तक, आपको केवल इस परिदृश्य के लिए एक अच्छा सुधार दिखाई देगा:
_ rerun watch और केवल अगर आप एक फ़ाइल के खिलाफ चलाते हैं (पहले रन पर नहीं) _
-> 2 / 3sec ड्रॉप 0.4 / 0.5sec के लिए।
लेकिन मैक की तुलना में मैंने कभी कोशिश नहीं की ... इसलिए शायद यह अभी भी बुरा है ... यहां तक ​​कि वर्तमान सुधार के साथ भी

@SimenB

1. मैं https://github.com/facebook/jest/issues/7110 को जेस्ट स्पीड रिग्रेशन [v22 बनाम v23] के रूप में विंडोज पर सभी समस्याग्रस्त परिदृश्यों के लिए मानता हूं।
   जहाँ # 6783 उनमें से एक है

2. मैं इस मुद्दे पर विचार कर सकता हूं: सभी समस्याग्रस्त परिदृश्यों के लिए जेस्ट [मैक बनाम विंडोज] के लिए गति समस्या।

हैलो सभी को !
मैं वेस्ट 24 और विंडोज़ 10 (400 टेस्ट के लिए 800) की सुस्ती को कम करता हूं। इस सबको तेज करने के लिए मैंने जिस तेजी से रास्ता खोजा, वह है कि पॉवरशेल या सीएमडी के बजाय डब्ल्यूएसएल का उपयोग करें। अब मेरा परीक्षण "केवल" 189s लेता है।

हमारे पास 1302 परीक्षणों के साथ 144 परीक्षण फाइलों का एक सूट है, जो विंडोज 10 बिल्ड 15063 मशीन पर चलने के लिए 1 मिनट और 43 सेकंड का समय लेता है, कोर आई 7 16 जीबी के साथ है, और वे मैक ओएस मोजवे पर 32 जीबी के साथ 28 सेकंड लगते हैं। हमारी विकास टीम समान रूप से विंडोज और मैक के बीच विभाजित है और संख्या बहुत दोहराई जाती है।

यहाँ एक सरल परीक्षण है -

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

मैंने इसे कोडेंडबॉक्स में डाल दिया है और यह बहुत ही तुरंत चलता है - https://codesandbox.io/s/4qcoin0q52lw

मेरी विंडोज मशीन पर हालांकि इसमें 4-5 सेकंड का समय लगता है -

PASS src / index.test.js
v काम करता है (62ms)

टेस्ट सूट: 1 पास, 1 कुल
टेस्ट: 1 उत्तीर्ण, 1 कुल
स्नैपशॉट: 0 कुल
समय: 4.158 से
सभी परीक्षण सूट भागा।

परीक्षण ने स्वयं 62ms लिया, लेकिन बाकी परीक्षण में 4 सेकंड का समय लगा। Enter को दबाकर परीक्षण को फिर से चलाना, इसमें उतना ही समय लगता है।

मेरी सेटिंग्स -

> npx envinfo --preset jest

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

मैंने इसे WSL उबंटू के साथ आजमाया और वही परिणाम मिले (4-5 सेकंड) - उन सेटिंग्स -

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

मैं सिर्फ जेस्ट के साथ शुरू कर रहा हूं इसलिए बहुत सरल परीक्षण हैं, और उन्हें चलाने में 15-20 सेकंड लग सकते हैं। मैं उन्हें जल्दी से दौड़ने के लिए प्यार करता हूँ - मुझे अपनी सोच की ट्रेन को खोना पड़ता है अन्यथा!

@bburns उपरोक्त मुद्दे को पढ़ते हैं

@kensherman
क्या आप अपने यार्न प्रस्तावों में 4 माइक्रोमीटर के साथ कोशिश कर सकते हैं। कृपया देखें कि क्या यह विंडोज़ में बेहतर है?
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

मैं एक नए मैकबुक प्रो पर हूं। चूंकि मेरे पास मैकओएस और विंडोज 10 दोनों पर छात्र हैं, इसलिए मैंने अपने ड्राइव में दो और विभाजन जोड़ने का फैसला किया; विंडोज 10 के लिए एक और टक्सरा NTFS का उपयोग करके साझा स्टोरेज के लिए एक।

मैं आज एक जावास्क्रिप्ट पाठ तैयार करने के लिए इस गति मुद्दे में भाग गया जिसमें यूनिट परीक्षण शामिल हैं। मैं वास्तव में MacOS से Jest चला रहा हूं लेकिन कोड और परीक्षण साझा NTFS विभाजन पर स्थित हैं। यहां तक ​​कि सभी सूटों को describe.skip के रूप में चिह्नित किया गया है, जेस्ट को पूरा होने में 10 सेकंड से अधिक लगते हैं, दोनों एकल-रन और वॉच मोड में।

8 सूट
42 परीक्षण

मैंने jest mocha और chai jest लिए स्वैप किया और रन लगभग 1 सेकंड सिंगल और 10 मिलीसेकंड वॉच मोड पर वापस आ गया।

मैंने मोचा और ची के लिए जेस्ट स्वैप किया और रन लगभग 1 सेकंड सिंगल और 10 मिली सेकेंड वॉच मोड पर वापस आ गया।

मूल रूप से आपने मेरी पिछली पोस्ट नहीं पढ़ी। आप mocha/chai को बढ़ावा देना चाहते थे ... हम सभी इस बारे में जानते हैं ... हम जेस्ट के प्रतिगमन को तय करने की कोशिश कर रहे हैं। या तो आप ऐसा करने में मदद करें [मेरी पोस्ट से] ...can you try with micromatch 4... या इन बेकार टिप्पणियों को धागे से बाहर रखें। प्रत्यक्ष होने के लिए क्षमा करें, लेकिन कुछ बिंदु पर इसे कहने का कोई अन्य तरीका नहीं है।

@nasreddineskandrani मैं हूं, लेकिन मैं अभी भी बेहद धीमी गति से निष्पादन देख सकता हूं जब घड़ी मोड के साथ चलने पर किसी भी मदद की बहुत सराहना की जाएगी।

@pachumon जहां तक ​​मुझे समझ में आया,

आपको प्रदर्शन के मुद्दे (सैद्धांतिक रूप से) को हटाने के लिए जेस्ट की एक निर्भरता को एक विशिष्ट संस्करण पर सेट करने की आवश्यकता है, फिक्स डिफ़ॉल्ट रूप से jest में मौजूद होगा 25 => यह जानने के लिए यहां पढ़ें कि कैसे एक देव को यह पता चलता है https://github.com/ फेसबुक / जेस्ट / मुद्दों / 7963 # जारीकरण -483985345

निर्भरता (micromatch) को उस संस्करण पर सेट करने के लिए जहां फिक्स किया गया था => आप यहां देख सकते हैं कि मैंने थोड़ी सी परियोजना में एक उदाहरण दिया था
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

अपने package.json : ( yarn npm उपयोग नहीं करना चाहिए)

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

उम्मीद है की यह मदद करेगा! और प्रतिक्रिया की प्रतीक्षा कर रहा है

मेरे टेस्ट रन का समय भी 24.6.1 को 24.6.1 और 24.8.0 को ~ 2.5 मिनट से 23.6.0 से ~ 15 मिनट तक का है। हमारा CI सर्वर विंडोज़ चला रहा है और इस अपग्रेड के साथ बिल्ड टाइम में समान रूप से बड़ी वृद्धि देखी गई है। मैंने micromatch निर्भरता रिज़ॉल्यूशन ओवरराइड की कोशिश की है जैसा कि ऊपर उल्लेख किया गया है @nasreddineskandrani से कोई फायदा नहीं हुआ। कृपया मुझे बताएं कि अगर ऐसा कुछ है तो मैं इसका निदान करने में सहायता कर सकता हूं।

@TomMahle यह एक सुपर खराब न्यूज़ है :( हम जिस शीर्ष के बारे में बात कर रहे हैं वह पहले से ही 23.6 में था)
अभी एक साधारण 'सैंपल' प्रोजेक्ट ने अच्छा प्रदर्शन दिखाया। micromatch अद्यतन के बाद।
इसलिए हमें डिबग करने के लिए वास्तविक समस्याग्रस्त परियोजना की आवश्यकता है, आप परियोजना निजी है? या सार्वजनिक?

micromatch @nasreddineskandrani के बारे में सुझाव के लिए धन्यवाद, लेकिन ऊपर @TomMahle की तरह, इसे ^4.0.0 पिन करना मेरे लिए प्रदर्शन को बेहतर बनाने के लिए प्रतीत नहीं हुआ। 😢

मुझे एक मजेदार बात पता चली, हालाँकि, जो इस समस्या का निदान करने में मदद कर सकती है।

मैं अपने विंडोज़ फाइल सिस्टम से मुख्य ऐप निर्देशिका के साथ डॉक कंटेनर में अपने मूल विंडोज़ सिस्टम पर या तो जैस्ट चलाने की क्षमता रखता हूं। गैर-वॉच मोड में चलने से लगता है कि दोनों प्रणालियों में लगभग समान व्यवहार है, जो शायद @thebearingedge के रूप में

हालांकि, वॉच मोड पर, चीजें थोड़ी अलग हैं: देशी खिड़कियां हमेशा उम्मीद के मुताबिक धीरे-धीरे काम करती हैं, लेकिन डॉक कंटेनर केवल पहले रन पर धीरे-धीरे परीक्षण चलाता है। एक बार जब मैं इसे दूसरी बार किसी भी परीक्षण सूट को चलाने के लिए कहता हूं (जैसे पी दबाकर और एक पैटर्न दर्ज करके), यह एक सेकंड के तहत अच्छी तरह से परीक्षणों को चलाता है (देशी खिड़कियों में समान 3-4 सेकंड लगते हैं)। Docker का उपयोग करने का एकमात्र नकारात्मक पहलू यह है कि फ़ाइल परिवर्तन ईवेंट्स को मेरी विंडोज़ वॉल्यूम से docker तक प्रचारित नहीं किया जाता है, इसलिए मुझे मैन्युअल रूप से प्रेस को फिर से चलाने के लिए एंटर दबाना होगा बजाय इसके कि jest do it स्वचालित रूप से हो, लेकिन मुझे लगता है कि हाथ में मुद्दे के लिए प्रासंगिक नहीं है।

@rasreddineskandrani दुर्भाग्य से मेरी परियोजना निजी है। यदि कोई छोटा कोड सैंपल (jest config?) या आँकड़े हैं, तो मैं यह प्रदान कर सकता हूँ कि मैं ऐसा करने में प्रसन्न हूँ। सभी परीक्षण नाटकीय रूप से धीमे (केवल खिड़कियों पर) प्रतीत होते हैं, इसलिए मुझे नहीं लगता कि इसका विशिष्ट परीक्षणों के साथ क्या करना है।

मैं अपने व्यक्तिगत वेबसाइटों के लिए एक docker सामान पूरा कर रहा हूं -> (एक सप्ताह के बाद) मैं इस पर वापस आ जाऊंगा।

@TomMahle
मैं आपकी समस्या का वर्णन करने के लिए एक रेपो जीथब रखने की कोशिश करूंगा।

1. आपके पास कितने परीक्षण हैं?
2. क्या आप परीक्षणों के लिए dom मोड सक्षम कर रहे हैं?
3. यह प्रतिक्रिया या कोणीय है?
   बक्शीश:
4. क्या आप डिबग करने में सक्षम होने के लिए गितुब रेपो में समस्या को पुन: उत्पन्न करने का प्रयास कर सकते हैं?
   आप मेरा कांटा कर सकते हैं: https://github.com/nasreddineskandrani/benchmark_jest
   या
5. शायद अपने परीक्षण मशीन पर मेरे रेपो की कोशिश करो? और परिणाम देखें? 23.6 और 24 के बीच

मुझे लगा कि माइक्रोचैच के रख-रखाव पर पर्याप्त ध्यान दिया गया है ताकि यह पहले ही समाप्त हो गया हो। खिड़कियों पर दौड़ना (इस प्रकार लिखना) जेस्ट परीक्षण इस समय बहुत अप्रिय अनुभव है।

मैं तब से मोचा / ची में चला गया हूं, लेकिन मुझे आश्चर्य है कि इस मुद्दे पर अभी भी काम किया जा रहा है।

स्पष्टीकरण

मैंने --runInBand का उपयोग किया, लेकिन ऐसा लग रहा था कि भावना के आधार पर, प्रत्येक अतिरिक्त 0.2 सेकंड से इकाई परीक्षणों को थोड़ा धीमा कर दिया है।

=> क्या आपने v24 के साथ प्रयास किया? v23 से v24 तक, आपको केवल इस परिदृश्य के लिए एक अच्छा सुधार दिखाई देगा:
_ rerun watch और केवल अगर आप एक फ़ाइल के खिलाफ चलाते हैं (पहले रन पर नहीं) _
-> 2 / 3sec ड्रॉप 0.4 / 0.5sec के लिए।
लेकिन मैक की तुलना में मैंने कभी कोशिश नहीं की ... इसलिए शायद यह अभी भी बुरा है ... यहां तक ​​कि वर्तमान सुधार के साथ भी

@SimenB

1. मैं विंडोज़ पर सभी समस्याग्रस्त परिदृश्यों के लिए # 7110 को जेस्ट स्पीड रिग्रेशन [v22 बनाम v23] मानता हूं।
   जहाँ # 6783 उनमें से एक है

2. मैं इस मुद्दे पर विचार कर सकता हूं: सभी समस्याग्रस्त परिदृश्यों के लिए जेस्ट [मैक बनाम विंडोज] के लिए गति समस्या।

मैंने पोस्ट के उस समय दोनों संस्करणों के साथ कोशिश की।

मैंने सिंपल एरे पुश टेस्ट के साथ एक टेस्ट के साथ एक नया प्रोजेक्ट बनाया और इसे शुरू होने से लेकर पूरा होने तक 10 सेकंड से अधिक समय लगा। परियोजना प्रतिक्रिया / टाइपस्क्रिप्ट का उपयोग कर रही है लेकिन परीक्षण फ़ाइल एक प्रतिक्रिया घटक फ़ाइल नहीं है, लेकिन एक .js जैसी सामान्य फ़ाइल है। दृश्य संदर्भ के लिए नीचे Gif अगर यह मुद्दा क्या हो सकता है कल्पना करना बेहतर बनाता है:

मैंने देखा कि पहली बार जब मैं परीक्षण चलाता हूं तो पता चलता है कि परीक्षण 9 सेकंड का होने का अनुमान है। एक बार जब यह पूरा हो जाता है, तो यह बेतरतीब ढंग से परीक्षणों को दूसरी बार पूरा करने के लिए पुन: प्रयास करता है।

जब मैंने उस जीआईएफ चित्र को ऊपर ले लिया (जो इस बार दूसरी बार था), तो अनुमान लगाया गया कि समय थोड़ा कम हो गया है और यह दूसरी बार प्रदर्शन नहीं कर पाया। यकीन नहीं होता है कि अगर यह अपेक्षित व्यवहार है।

यहाँ मुझे एक अलग परियोजना में यार्न के साथ माइक्रोमीटर 4 चल रहा है:

विंडोज़ 10 और मेरे कंप्यूटर स्पेक्स का उपयोग कर रहे हैं:
एएमडी एफएक्स (टीएम) -8320 आठ-कोर प्रोसेसर 3.50GHz
16 जीबी रैम
64
एसएसडी

मुझे यहाँ अपनी रूपरेखा साझा करने दीजिए।
ऐनक:

• विंडोज 10 प्रो
• नोड 10.15.3
• इंटेल कोर i7-4702MQ 2.2GHz
• 8 जीबी रैम
• 64
• एसएसडी

कदम:

1. npx create-react-app my-app --typescript
2. App.test.tsx बदलें
3. npm test चलाएं

सीपीयू प्रोफाइल:

CPU-20190801T141211.zip

क्या यह अपेक्षा की जाती है कि 15 सेकंड केवल एकल तुच्छ प्रतिक्रिया घटक और परीक्षण के लिए पुन: प्रयोज्य मॉड्यूल के साथ खर्च किए जाते हैं?

सीपीयू प्रोफाइलिंग पर अधिक अनुभव के साथ कोई देख सकता है?

112 का परीक्षण किया
विंडोज 10
पहले 507 सेकंड चलाएं
दूसरा 23 सेकंड चला
लिनक्स उप प्रणाली
फ्रिस्ट 54 सेकंड चलाते हैं
दूसरा भाग 29 सेकंड

85 परीक्षण
विंडोज 10
पहले 44 सेकंड दौड़ें
दूसरा सेकंड 15 सेकंड
लिनक्स उप प्रणाली
पहले 26 सेकंड चलाएं
दूसरा सेकंड 15 सेकंड

Kepro ये परिणाम 4 micromatch के साथ हैं?

मैं 1 लाख संदेश होने की तुलना में प्रत्यक्ष चैट को प्राथमिकता देता हूं। यह वास्तव में सभी विषयों को पार करने के लिए एक नरक है जो एक ही विषय से संबंधित हैं।
आप यहां शामिल हो सकते हैं। https://gitter.im/wearefrontend/jest-slow-windows
मैं अब इस पर हूँ ...

मेरी कंपनी वीपीएन पर Gitter अवरुद्ध है - यदि आप प्यारे लोग यहां कोई सार्थक अपडेट पोस्ट कर सकते हैं जो कि अद्भुत <3 होगा

आप अभी भी कुछ खुले स्रोत करने के लिए घर पर कनेक्ट कर सकते हैं: पी और इसे जांचें
ps एक डोटा गेम को कतार में अधिक समय लगता है अब आप इस समय में गटर की जांच कर सकते हैं;)
यह वह जगह है जहां यह अब है: # 28946 नोड्स / नोड

@rasreddineskandrani आप मुझे मिल गए। मैंने एक नई मैकबुक का आदेश दिया है, इसलिए जब तक यह ओपन-सोर्स एक्शन से बाहर नहीं होगी। मैं वास्तव में अपने खाली समय में मेरे भद्दे विंडोज बॉक्स पर काम करने से इनकार करता हूं: डी

ऐसा लगता है कि मुद्दा नोड / सी ++ दायरे में चला गया है, जो कि मेरे कम्फर्ट ज़ोन के बाहर थोड़ा (बेहद) है - लेकिन मैं कुछ खुदाई करूँगा!

हाय इस पर कोई खबर?

यदि आप एक से अधिक परीक्षण शुरू करते हैं तो वर्कअराउंड के रूप में --runInBand का उपयोग कर सकते हैं। पहला परीक्षण शुरू होने में अभी भी लंबा समय लगेगा लेकिन अगले परीक्षण तेजी से होंगे।

मेरी परियोजना ने सभी परीक्षणों को निष्पादित करने के लिए 21.803s लिया।
--RunInBand के साथ अब यह केवल 7.412 का है

मेरे लिए -runInBand इसे और भी धीमा कर दें। 1200 टन। बिना रनबिनैंड 70/50 सेकंड के। --RunInBand के साथ अपने 90 रन के साथ दूसरे नंबर पर सर्वश्रेष्ठ
लाइनक्स पर इसकी तरह 5-8x तेजी से

कोशिश करो - maxWorkers = 4 तो।

@ cino893 , समाधान नहीं :) एक समाधान नहीं हल खोजने की कोशिश करें

उस पर कोई खबर? मैं उस बग के कारण संस्करण 21 पर ढेर हो गया। v22 धीमा है और v23 भी धीमा है।
क्या आप लोगों को नहीं लगता कि यह उच्च प्राथमिकता वाला बग है?

जहां मैं काम करता हूं, हमें ओएस चुनने की आजादी नहीं है और न ही विंडो या कुछ इसी तरह से उबंटू स्थापित करने की।

@gombek क्या आपने v25

नमस्ते, बस मैंने सोचा कि मैं इस चर्चा में कुछ अतिरिक्त जानकारी जोड़ूंगा। जब डॉकर कंटेनर के अंदर निष्पादित किया जाता है, तो जेस्ट सुपर स्लो होता है, जिसमें होस्ट सिस्टम (विंडोज) से वॉल्यूम के माध्यम से स्रोत कोड और परीक्षण साझा किए जाते हैं।

मुझे पूरा यकीन है कि यह स्लोडाउन यूनिक्स सिस्टम की तुलना में विंडोज हैंडल के हैंडल के अंतर के कारण है। यूनिक्स में, यदि किसी प्रक्रिया में एक फ़ाइल हैंडल खुला होता है जो उस फ़ाइल को पढ़ने से अन्य प्रक्रियाओं को अवरुद्ध नहीं करता है। विंडोज में, फाइल हैंडल रखने वाली एक प्रक्रिया उस फाइल का मालिक होती है, जब तक वह हैंडल को रिलीज करती है। मैं फाइल रीडिंग लॉजिक के लिए जेस्ट कोड देखूंगा और विशेष रूप से फाइल हैंडल कब और कैसे जारी किया जाता है। एक अच्छी तरह से व्यवहार करने वाले कार्यक्रम को किसी भी तरह से फ़ाइल हैंडल को तुरंत जारी करना चाहिए जब उसने काम किया हो। जेस्ट जैसे टेस्ट रनर के पास वैसे भी लंबे समय तक फाइल हैंडल रखने का कोई कारण नहीं होना चाहिए।

@gombek क्या आपने v25

मैं विंडोज़ पर जेस्ट वी 25 का उपयोग कर रहा हूं और यह अभी भी धीमा है

@pfftdammitchris मैंने मैक + विंडोज पर सुंदर जटिल परीक्षण सूट की तुलना की है और मुझे कुछ अंतर दिखाई देते हैं, मुख्य रूप से एक ठंडा कैश विंडोज से काफी धीमा है, लेकिन एक बार जब मैं गर्म होता हूं तो दोनों के बीच समान प्रदर्शन मिलता है।

तथापि...

विशेष रूप से विंडोज पर बेहद सावधान रहने वाली एक चीज है एंटिवाइरस / फाइल-वॉचर्स जैसे कार्बन ब्लैक (या अन्य रियल-टाइम फाइल वॉचिंग सॉफ्टवेयर) जैसे घुसपैठ कर्नेल-स्तरीय कार्यक्रम। यदि आपके पास ऐसा कुछ चल रहा है, तो आप JEST को चलाते समय बहुत बड़ा प्रदर्शन देख सकते हैं। मैं परीक्षण चलाने के लिए दसियों मिनट लगने के बारे में बात कर रहा हूं।

मैंने पिछले साल एक कंपनी के लिए काम किया था, जहां एक ही टेस्ट सूट ने मैकबुक प्रो पर 30 सेकंड का समय लिया था और विंडोज फाइल पर 20 मिनट तक ये फाइल देखने वाले प्रोग्राम चलते थे।

मुझे पता नहीं क्यों, लेकिन मुझे लगता है कि यह फ़ाइल-हैंडल के साथ कुछ करने के लिए एक अनुमान को खतरा होगा और जेस्ट नोड के कुछ फाइल सिस्टम एपीआई का उपयोग कैसे करता है।

मेरे पास केवल 20 परीक्षण हैं और मैंने अभी-अभी jest --watch के साथ कुछ समय लिया है, दोनों इंटियल रन पर और फिर उन्हें फिर से चलाने के लिए एंटर दबा रहे हैं।

विंडोज पर दोनों समय लगभग 15 सेकंड लगे जबकि लिनक्स के लिए यह पहले रन के लिए लगभग 5.3 सेकंड और बाद के रन पर 2.3 था।

मैंने सभी परीक्षणों को छोड़ देने के कारण -t = "GARBAGE" का उपयोग करने का प्रयास किया। लिनक्स को 1.5 सेकंड का समय लगता था, लेकिन विंडोज़ में अभी भी 13 का समय लगता था, इसलिए मुझे लगता है कि यह समय लगने वाले परीक्षणों की वास्तविक दौड़ नहीं है!

दोनों मशीनें नोड और जेस्ट के नवीनतम संस्करण का उपयोग कर रही हैं, और लिनक्स वास्तव में एक वीएम है जो हाइपर-वी का उपयोग करके विंडोज एक के अंदर चल रहा है, इसलिए अन्य चीजें समान होने के नाते मैं विंडोज के तेजी से होने की उम्मीद करूंगा।

मेरे पास केवल 20 परीक्षण हैं और मैंने अभी-अभी jest --watch के साथ कुछ समय लिया है, दोनों इंटियल रन पर और फिर उन्हें फिर से चलाने के लिए एंटर दबा रहे हैं।

विंडोज पर दोनों समय लगभग 15 सेकंड लगे जबकि लिनक्स के लिए यह पहले रन के लिए लगभग 5.3 सेकंड और बाद के रन पर 2.3 था।

मैंने सभी परीक्षणों को छोड़ देने के कारण -t = "GARBAGE" का उपयोग करने का प्रयास किया। लिनक्स को 1.5 सेकंड का समय लगता था, लेकिन विंडोज़ में अभी भी 13 का समय लगता था, इसलिए मुझे लगता है कि यह समय लगने वाले परीक्षणों की वास्तविक दौड़ नहीं है!

दोनों मशीनें नोड और जेस्ट के नवीनतम संस्करण का उपयोग कर रही हैं, और लिनक्स वास्तव में एक वीएम है जो हाइपर-वी का उपयोग करके विंडोज एक के अंदर चल रहा है, इसलिए अन्य चीजें समान होने के नाते मैं विंडोज के तेजी से होने की उम्मीद करूंगा।

हाँ। और अगर आप विंडोज से लिनक्स वीएम के लिए स्रोत कोड को माउंट करते हैं और उन परीक्षणों को चलाते हैं जो वे विंडोज में जितने धीमे होते हैं। इसका तात्पर्य यह है कि समस्या जेस्ट की फ़ाइल हैंडलिंग लॉजिक में है जैसा कि मैंने पहले उल्लेख किया है।

हाँ। और अगर आप विंडोज से लिनक्स वीएम के लिए स्रोत कोड को माउंट करते हैं और उन परीक्षणों को चलाते हैं जो वे विंडोज में जितने धीमे होते हैं। इसका तात्पर्य यह है कि समस्या जेस्ट की फ़ाइल हैंडलिंग लॉजिक में है जैसा कि मैंने पहले उल्लेख किया है।

मैंने देखा कि जब परीक्षण चल रहे हैं तो सीपीयू अधिक है लेकिन डिस्क का उपयोग नहीं है। यह फ़ाइल हैंडल पर अवरुद्ध करने के साथ करना था, मैं इसे कम सीपीयू होने की उम्मीद करूंगा (जब तक कि किसी तरह से तंग लूप में जस का तस रिलीज होने का इंतजार न हो)

मैंने फ़ाइल देखने वालों पर hevans90 की टिप्पणियों को देखा। मेरे पास कोई तृतीय-पक्ष एंटी-वायरस स्थापित या समान स्थापित नहीं है, लेकिन विंडोज में निर्मित वास्तविक समय की सुरक्षा को अक्षम करने से कोई ध्यान देने योग्य अंतर नहीं हुआ।

आशा है कि अगर किसी के पास मदद करने के लिए और इसे डिबग करने का समय है, तो इससे कुछ मदद मिलेगी।

इसलिए मैंने आज पुष्टि की है कि विंडोज डिफेंडर एक बड़ा अंतर बनाता है।
मेरे पास अपवर्जन का एक गुच्छा हुआ करता था, लेकिन जब मुझे अपना नया तेज लैपटॉप मिला, तो मैं अपने जीवन का पता नहीं लगा सका कि एक फाइल को चलाने में जेस्ट को 10 मिनट क्यों लगे।

तब मुझे बहिष्करण याद आया।
मैं बिल्कुल नहीं बता सकता कि कौन से बहिष्करण से फर्क पड़ता है, लेकिन मुझे धावक के लिए नीचे जाना है

मुझे प्रासंगिक बहिष्करणों के साथ एक जिस्ट मिला (यद्यपि बलशाली)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
मैंने फ़ाइल एक्सटेंशन .ts .js .spec.ts .spec.js .tsx भी जोड़े

मैं बिल्कुल नहीं बता सकता कि कौन से बहिष्करण से फर्क पड़ता है, लेकिन मुझे धावक के लिए नीचे जाना है

हम्म मैंने अभी कोशिश की है और इससे मुझे कोई फर्क नहीं पड़ता है (आप पर ध्यान दें, मेरा मिनट नहीं था, इसलिए शायद हम अलग-अलग समस्याएं हैं)

मैं हमेशा किसी भी जगह पर बहिष्कार करता हूं। और वास्तव में इंटेलीज आइडिया स्वचालित रूप से कार्यक्षेत्र निर्देशिका को बहिष्करण में रखने का सुझाव देता है और ऐसा आपके लिए करता है यदि आप इसे (आपको करना चाहिए) करते हैं। तो मेरे मामले में सुस्ती विंडोज डिफेंडर या किसी अन्य वायरस स्कैनर के कारण नहीं है।

मैक की तुलना में प्रदर्शन अंतर 5-10x है। पीसी एक शक्तिशाली डेस्कटॉप मशीन है (पढ़ें: मैकबुक से बहुत तेज)। बाकी सब कुछ तेज़ है, बस जेस्ट इस मुद्दे से पीड़ित है।

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

इस मुद्दे को भी। एक एकल, हैलो विश्व परीक्षण के साथ एक एकल परीक्षण फ़ाइल और शुरू होने में ~ 15 सेकंड लगते हैं, और परीक्षण चलाने के लिए एक और 12 सेकंड।

👋 मुझे कुछ उत्तर दिखाई दे रहे हैं कि वे जेस्ट के साथ टाइपस्क्रिप्ट का उपयोग कर रहे हैं - यह देखने लायक हो सकता है (यदि आप ts-jest का उपयोग भी कर रहे हैं): https://github.com/kulshekhar/ts-jest/issues/ 908 # जारीकरण -484043250

मेरे लिए बदलाव केवल कुछ सेकंड के लिए शुरू करने के लिए जेस्ट (कैश के बिना) के लिए 30 मिनट इंतजार करने से जा रहा था।

ध्यान रखें कि आइसोलेट्समॉडल के फ्लैग को सेट करने से आपकी स्पेक फाइल्स (और कुछ कार्यक्षमता का नुकसान) के लिए कोई प्रकार की जाँच नहीं होगी: https://github.com/kulshekhar/ts-jest/blob/master/docs/user )

मैं इसे केवल यहां पोस्ट कर रहा हूं क्योंकि यह निर्धारित करने के लिए उपयोगी हो सकता है कि आपका मुद्दा जेस्ट के साथ है।

👋 मुझे कुछ उत्तर दिखाई दे रहे हैं कि वे जेस्ट के साथ टाइपस्क्रिप्ट का उपयोग कर रहे हैं - यह देखने लायक हो सकता है (यदि आप ts-jest का उपयोग भी कर रहे हैं): kulshekhar / ts-jest # 908 (टिप्पणी)

मेरे लिए बदलाव केवल कुछ सेकंड के लिए शुरू करने के लिए जेस्ट (कैश के बिना) के लिए 30 मिनट इंतजार करने से जा रहा था।

ध्यान रखें कि आइसोलेट्समॉडल के फ्लैग को सेट करने से आपकी स्पेक फाइल्स (और कुछ कार्यक्षमता का नुकसान) के लिए कोई प्रकार की जाँच नहीं होगी: https://github.com/kulshekhar/ts-jest/blob/master/docs/user )

मैं इसे केवल यहां पोस्ट कर रहा हूं क्योंकि यह निर्धारित करने के लिए उपयोगी हो सकता है कि आपका मुद्दा जेस्ट के साथ है।

शुद्ध जावास्क्रिप्ट यहाँ। मेरे पास यह समस्या है इसलिए टाइपस्क्रिप्ट से संबंधित नहीं है।

FYI करें: https://github.com/kulshekhar/ts-jest/pull/1549 ts-jest (संभवतः आज) के अल्फा संस्करण में होगा। जो कोई भी ts-jest का उपयोग कर रहा है, कृपया अल्फा संस्करण का परीक्षण करने में मदद करें और हमें https://github.com/kulshekhar/ts-jest/issues/1115 के लिए कुछ प्रतिक्रियाएं दें

इस मुद्दे को भी। एक एकल, हैलो विश्व परीक्षण के साथ एक एकल परीक्षण फ़ाइल और शुरू होने में ~ 15 सेकंड लगते हैं, और परीक्षण चलाने के लिए एक और 12 सेकंड।

बस एक मैक पर एक ही परीक्षण भाग गया। शुरू करने के लिए लगभग 1.5secs लगते हैं, परीक्षण चलाने के लिए <1sec।

जेएस का उपयोग करते हुए, यहां टीएस नहीं।

शुद्ध जावास्क्रिप्ट यहाँ जेस्ट के साथ साथ। मेरे पास इंटेल के 10gen प्रोसेसर के साथ एक शक्तिशाली क्वाड कोर लैपटॉप है और बाकी सब कुछ तेजी से धधक रहा है, लेकिन कुछ बुनियादी परीक्षणों को चलाने के लिए विंडोज बनाम लिनक्स पर [email protected] 2-3 गुना अधिक ले रहा है।

एक ही मुद्दा, विंडोज़ पर चलने के लिए मेरे परीक्षणों के बारे में 60 सेकंड, और पहले 45 सेकंड या इसके लिए कोई UI प्रदर्शित नहीं किया गया है। मेरे linux मशीन पर एक ही सटीक परीक्षण सूट चला और इसे पूरा होने में 8 सेकंड का समय लगा।

नाटकीय रूप से लगभग 15 सेकंड के ऊपर @Cellule की टिप्पणी।

@ryanrapini ने @Cellule की सलाह का पालन किया (लेकिन Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions माध्यम से चला गया) और देखा कि कुछ परीक्षण 13 सेकंड से 6 तक चले गए, इसलिए मूल रूप से आधा था। धन्यवाद!

वेबसाइट के FAQ पृष्ठ पर कोई भी व्यक्ति विंडोज डिफेंडर (या सामान्य रूप से AV?) का उल्लेख करने वाले अनुभाग में योगदान दे सकता है। https://jestjs.io/docs/en/troublesourcing

मैं पुष्टि कर सकता हूं कि ts-jest के साथ isolatedModules: true का उपयोग करके ठंडे स्टार्टअप पर एक बड़ा अंतर आया (~ 10mins => 15sec)
मैंने अल्फा में उनके सुधार का परीक्षण नहीं किया है क्योंकि मैं # 9457 पर प्रतीक्षा कर रहा हूं, जो 25 साल पहले अद्यतन करने से पहले संबोधित किया जाएगा

नमस्ते,

एक ही समस्या यहाँ और कोई समाधान मेरे लिए काम करता है ...

मैं कुछ बहुत ही सरल कोड चलाता हूं जिस पर मेरे पास वर्तमान में कुछ परीक्षण हैं।
यह वेस बो के "एडवांस्ड रिएक्ट कोर्स" से है।
वह इसे मैक पर चलाता है, और अपने कंप्यूटर से तत्काल उत्तर प्राप्त करता है।

और मेरे लिए:

टेस्ट सूट: 2 स्किप्ड, 15 पास, 15 कुल 17
टेस्ट: 6 स्किप, 37 पास, 43 कुल
स्नैपशॉट: 18 पास, कुल 18
समय: ५. 5.६ ९
सभी परीक्षण सूट भागा।

isolatedModules: true मेरे मामले में कुछ भी नहीं बदलता है, मैं अभी भी 5-6 सेकंड के आसपास हूं।
और जब मैं किसी भी विकल्प के साथ परीक्षण शुरू करता हूं, तो 9 ~ 10 सेकंड लगते हैं।

डिफेंडर अपवाद पर मेरे देव फ़ोल्डर को जोड़ने से कुछ भी नहीं हुआ:

टेस्ट सूट: 2 स्किप्ड, 15 पास, 15 कुल 17
टेस्ट: 6 स्किप, 37 पास, 43 कुल
स्नैपशॉट: 18 पास, कुल 18
समय: 5.563 बजे
सभी परीक्षण सूट भागा।

क्या विंडोज पर कोई अच्छा विकल्प है?
क्या मुझे wsl2 के लिए जाने की आवश्यकता है?

नमस्ते,

एक ही समस्या यहाँ और कोई समाधान मेरे लिए काम करता है ...

मैं कुछ बहुत ही सरल कोड चलाता हूं जिस पर मेरे पास वर्तमान में कुछ परीक्षण हैं।
यह वेस बो के "एडवांस्ड रिएक्ट कोर्स" से है।
वह इसे मैक पर चलाता है, और अपने कंप्यूटर से तत्काल उत्तर प्राप्त करता है।

और मेरे लिए:

टेस्ट सूट: 2 स्किप्ड, 15 पास, 15 कुल 17
टेस्ट: 6 स्किप, 37 पास, 43 कुल
स्नैपशॉट: 18 पास, कुल 18
समय: ५. 5.६ ९
सभी परीक्षण सूट भागा।

isolatedModules: true मेरे मामले में कुछ भी नहीं बदलता है, मैं अभी भी 5-6 सेकंड के आसपास हूं।
और जब मैं किसी भी विकल्प के साथ परीक्षण शुरू करता हूं, तो 9 ~ 10 सेकंड लगते हैं।

डिफेंडर अपवाद पर मेरे देव फ़ोल्डर को जोड़ने से कुछ भी नहीं हुआ:

टेस्ट सूट: 2 स्किप्ड, 15 पास, 15 कुल 17
टेस्ट: 6 स्किप, 37 पास, 43 कुल
स्नैपशॉट: 18 पास, कुल 18
समय: 5.563 बजे
सभी परीक्षण सूट भागा।

क्या विंडोज पर कोई अच्छा विकल्प है?
क्या मुझे wsl2 के लिए जाने की आवश्यकता है?

क्या आप मेरे समाधान को लागू करने की कोशिश कर सकते हैं और मुझे बता सकते हैं कि क्या यह कुछ करता है? (वास्तव में सेल्युल का समाधान, लेकिन मैंने इसे स्क्रिप्ट चलाने के बजाय मेनू के माध्यम से किया)

क्या आप मेरे समाधान को लागू करने की कोशिश कर सकते हैं और मुझे बता सकते हैं कि क्या यह कुछ करता है? (वास्तव में सेल्युल का समाधान, लेकिन मैंने इसे स्क्रिप्ट चलाने के बजाय मेनू के माध्यम से किया)

जैसा कि मैंने अपने संदेश में कहा, मैंने पहले से ही ऐसा किया है :)

मेरा मतलब है कि मैंने मेनू और सभी के माध्यम से आपने जो किया, उसका पालन किया।

मैं भी विंडोज पर इस मुद्दे को कर रहा हूँ। परीक्षण खुद <1 सेकंड में चलता है लेकिन समग्र सेटअप निष्पादित करने के लिए ~ 15 सेकंड लेता है। मैंने इसे v24 और v26 के साथ आज़माया है, यह वास्तव में v26 पर थोड़ा धीमा है

मुझे निम्न में से किसी के साथ भाग्य नहीं था (यह निष्पादन समय में सुधार नहीं करता है):

• --runInBand जोड़ना
• maxWorkers
• @Cellule और @alessioalex द्वारा सुझाए गए .ts .js .spec.ts .spec.js .tsx बहिष्करणों को Virus and Threat Protection जोड़ने पर

वेनिला जावास्क्रिप्ट के साथ-साथ एक ताजा टाइपस्क्रिप्ट प्रोजेक्ट के साथ विंडोज पर भी यही मुद्दा है। 9 यूनिट परीक्षण चलाने के लिए 2 सेकंड जो मोचा का उपयोग करके <10ms में चलते हैं।

यह पागलपन है!

बस विश्व स्तर पर स्थापित किया गया jest और अब वही परियोजना 52 के बजाय 0.9 में चलती है (!!!) सेकंड!
npm remove jest परियोजना में, फिर
npm install -g jest

बेशक मैं फिर से इस परियोजना में देव निर्भरता के रूप में कीट को एकीकृत करना चाहूंगा। किसी भी विचार क्यों होता है?

यह पागलपन है!

बस विश्व स्तर पर स्थापित किया गया jest और अब वही परियोजना 52 के बजाय 0.9 में चलती है (!!!) सेकंड!
npm remove jest परियोजना में, फिर
npm install -g jest

बेशक मैं फिर से इस परियोजना में देव निर्भरता के रूप में कीट को एकीकृत करना चाहूंगा। किसी भी विचार क्यों होता है?

यह निश्चित रूप से मेरे लिए एक वायरस स्कैनर मुद्दे की तरह लगता है। मतलब, आपकी प्रोजेक्ट डायरेक्टरी वायरस स्केनिंग के दायरे में है जो कि क्रॉल को धीमा कर देती है लेकिन आपकी ग्लोबल एनपीएम डायरेक्टरी नहीं है। हालांकि यह सिर्फ एक अनुमान है।

मैंने अभी @JPustkuchen जैसी ही कोशिश की है और प्रदर्शन ~ 10s से <1 सेकंड तक चला जाता है।

मैंने अपने प्रोजेक्ट फोल्डर को विंडोज डिफेंडर से बाहर कर दिया लेकिन जेस्ट अभी भी धीमी गति से चल रहा है।

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

मैं इतना चाहूंगा कि कोई कम से कम यह स्वीकार करे कि यह एक समस्या है। जैसा कि यह अब है, मेरी विंडोज़ डेस्कटॉप मशीन जिसमें बहुत शक्ति है (पढ़ें: मेरे सह-कार्यकर्ता मैकबुक से बहुत अधिक) परीक्षण निष्पादित करते समय मैकबुक की तुलना में लगभग 69 गुना धीमा है! यह व्यावहारिक रूप से मुझे फ्रंटेंड कोड को छूने के लिए मजबूर नहीं करता है क्योंकि यह मेरे लिए इतना अक्षम है कि जेस्ट टेस्ट इतनी धीमी गति से चल रहे हैं। अगर यह ठीक नहीं हुआ तो हमें जेस्ट से दूर जाना पड़ सकता है। बाकी सब कुछ तेज़ है, लेकिन जेस्ट परीक्षण सुपरडुपर धीमा है। समय वास्तव में परीक्षणों को निष्पादित करने की तुलना में कुछ और पर खर्च किया जाता है, जब वास्तविक परीक्षण तर्क को निष्पादित किया जाता है जो वास्तव में तेजी से चलते हैं।

अधिक सकारात्मक नोट पर, मैं सिर्फ यह कहना चाहूंगा कि मैं इस बग को कृतज्ञता का एक बड़ा ऋण देना चाहता हूं। यह अंतिम स्ट्रॉ था जिसने मुझे अपने मुख्य विकास वर्कफ़्लो के लिए लिनक्स पर स्विच करने का निर्णय लिया और मैं कभी भी खुश नहीं हुआ। मैं यह नहीं कह सकता कि मैं कभी पीछे नहीं हटूंगा क्योंकि कभी-कभी मुझे विरासत परियोजनाओं पर काम करना पड़ता है, लेकिन ASP.NET कोर के क्रॉस-प्लेटफॉर्म होने के कारण, विंडोज़ में वापस बूट करने के कारण हर समय कम होते जा रहे हैं।

कृपया @ timrobinson33 चलो विषय पर jest विंडोज पर किसी भी अन्य वातावरण की तुलना में 68 गुना धीमा होना चाहिए, नोड पर विचार करना किसी भी मंच पर ठीक काम करता है। मैं भी जोड़ सकता हूं, मैंने किसी अन्य परीक्षण धावक के साथ इस समस्या का अनुभव नहीं किया है।

मैंने अपने बेंचमार्क jest github repo में v26.4.2 के साथ परीक्षण किया।
https://github.com/nasreddineskandrani/benchmark_jest
मेरे कंप्यूटर में नोड संस्करण: v12.13.0

जब मैं सरल परीक्षण (स्क्रीनशॉट देखें) को अपडेट करता हूँ तो बहुत अच्छा लगता है! मेरे लिए जेस्ट अब एक साधारण परीक्षा के लिए सही है।
अगर आपको अपनी नौकरी में समस्या है। आपको समस्या को अलग करने की कोशिश करने की आवश्यकता है क्योंकि डिफ़ॉल्ट रूप से यह ठीक है।

@ नीपर आप मेरे बेंचमार्क रेपो को

मैंने अपने बेंचमार्क jest github repo में v26.4.2 के साथ परीक्षण किया।
https://github.com/nasreddineskandrani/benchmark_jest
मेरे कंप्यूटर में नोड संस्करण: v12.13.0

जब मैं सरल परीक्षण (स्क्रीनशॉट देखें) को अपडेट करता हूँ तो बहुत अच्छा लगता है! मेरे लिए जेस्ट अब एक साधारण परीक्षा के लिए सही है।
अगर आपको अपनी नौकरी में समस्या है। आपको समस्या को अलग करने की कोशिश करने की आवश्यकता है क्योंकि डिफ़ॉल्ट रूप से यह ठीक है।

@ नीपर आप मेरे बेंचमार्क रेपो को

जैसा कि अपेक्षित था, आपके परीक्षण सेटअप प्रदर्शन में कोई अंतर नहीं है। आपके कंप्यूटर की तुलना में वास्तव में थोड़ा तेज चलता है। __tests__ तहत 100 परीक्षण फ़ाइलों को शामिल करने के लिए अपने परीक्षण सेटअप को बदल दिया और वे भी ठीक चल रहे हैं। चूँकि हमारा ऐप react-scripts का उपयोग करता है

फिर मैंने WSL2 बैश (NTFS फाइलसिस्टम के खिलाफ) और बूम, निष्पादन समय को लगभग 10 गुना करने की कोशिश की। NTFS के खिलाफ WSL2 पर धीमी I / O गति की उम्मीद की जानी है, लेकिन यह देखते हुए कि यह सेटअप कितना सरल है (हर एक पर एकल परीक्षण के साथ सिर्फ 100 परीक्षण फाइलें) यह वास्तव में इतना प्रभावित नहीं करना चाहिए। संदर्भ के लिए, मैंने इसे WSL2 बैश पर निष्पादित किया:

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

जो दिखाता है कि WSL2 से फाइल सिस्टम को पढ़ने के लिए व्यावहारिक रूप से बिल्कुल भी समय नहीं लगता है। Powershell में इसी तरह के कमांड के लिए:

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

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

जिससे पता चलता है कि प्रदर्शन उसी बॉलपार्क पर है।

इसलिए, इसके आधार पर मैं कहूंगा कि इस मुद्दे का कारण यह हो सकता है कि जेस्ट आई / ओ का उपयोग कैसे करता है और यह किसी भी तरह से WS42 पर नाटकीय रूप से प्रदर्शन को प्रभावित कर रहा है। जब यह उस परियोजना की बात आती है जो मुझे परेशान कर रही है तो कोड और परीक्षणों (मेरे द्वारा नहीं किया गया!) में मुद्दों के कारण बैश की आवश्यकता नहीं है यह एक सरल कार्य नहीं है। इस तथ्य को ध्यान में रखते हुए कि WSL2 लोकप्रियता प्राप्त कर रहा है, मैं कहूंगा कि यह एक वास्तविक मुद्दा है जिस पर ध्यान दिया जाना चाहिए।

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

: संपादित करें:

जिज्ञासा से बाहर मैंने अपने परीक्षण सूट को --no-watch साथ निष्पादित किया है यह देखने के लिए कि क्या WSL2 पर फ़ाइल सिस्टम देखने से किसी तरह चीजें प्रभावित होती हैं। जवाब नहीं है, यह वास्तव में इतना प्रभावित नहीं करता है।

मेरी विंडोज़ मशीन पर बेंचमार्क चलाने में लगभग 1.6s लगते हैं। मैं WSL का उपयोग नहीं कर रहा हूँ।
मैं एवीजी एंटीवायरस का उपयोग कर रहा हूं, लेकिन रिपॉजिटरी और नोड एक्जीक्यूटेबल दोनों के लिए अपवाद जोड़ दिए हैं।
मेरा हार्डड्राइव एक एसएसडी है।

नोड संस्करण v12.16.1

परीक्षण को अपडेट करना तुरंत फ़ाइल वॉचर को ट्रिगर करता है, लेकिन उस अपडेट को चलाने के लिए वास्तविक समय 1 एस-2.4 के आसपास है।

मैं परीक्षण करना चाहता था कि क्या यह पर्यावरण का मुद्दा है।

मैं इस रेपो के साथ खिलवाड़ कर रहा था: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• मैं npm test लिए जाता हूं और सभी परीक्षण घड़ी मोड में चलने लगते हैं।
• मैं फ़ाइल के लिए एक पैटर्न दर्ज करने के लिए 'p' दबाता हूं और "tdd-02" टाइप करता हूं। मुझे 3+ सेकंड का निष्पादन समय मिलता है।
  

मुझे आश्चर्य होगा कि केंट सी। डोड्स ने अपने भुगतान किए गए पाठ्यक्रम में एक गड़बड़ वातावरण बनाया है, लेकिन अगर वह करता है, तो आप इसे संभवतः डिबग कर सकते हैं:? अपने वीडियो में, यह ठीक चलता है, मुझे लगता है कि वह एक मैक का उपयोग करता है।

मुझे कुछ बहुत ही अजीब बात नोट करनी है, जिसे मैं फिर से नहीं दोहरा सकता - मेरे पास कुछ लगातार परीक्षण पुनर्मिलन थे जो कि फ़ाइलों में से एक के लिए (tdd-02 ... js) लगभग 0.1 के लिए निष्पादित किया गया था, और इसके बगल में फ़ाइल के लिए ( tdd-01 ... js) - लगभग 3 s। कोड लगभग समान है और समान निर्भरता का उपयोग करता है। इसलिए, मैंने कोड को फास्ट-रनिंग फ़ाइल से कॉपी किया और इसे स्लो-रनिंग वन और इसके विपरीत चिपकाया। परिणाम समान थे - धीमी गति से चलने वाली फ़ाइल धीमी रही और तेज़ चलने वाली फ़ाइल तेजी से बनी रही, जिसमें वास्तविक कोड स्वैप किए गए थे। यह पागल हो रहा है। अब दोनों फाइलें फिर से धीमी गति से चलती हैं (3-6s)।

@Glinkis आप पहले रन के बाद हिट दर्ज करने की कोशिश कर सकते हैं क्या यह अभी भी 1.6sec है? (फिर से दौड़ना)

@SimeonRolev मैं आपके द्वारा पोस्ट किए गए उदाहरण पर एक नज़र
अपडेट करें:
try1: मैंने इसे यू के रूप में आज़माया और 6sec मिला जब मैंने आपके चरणों की कोशिश की -> उसी परीक्षा में फिर से दौड़ने के लिए 3sec पर ड्रॉप करें (हिट दर्ज करें)
try2: केंट रेपो में 26.4 में अपग्रेडेड जस्ट -> 3 सेकेंड पहले रेरून के लिए उसी के पास चलता है
try3: मैंने अपने बेंचमार्क टेस्ट रेपो से index.spec.js फ़ाइल ली। और मैंने इसे केंट रेपो में गिरा दिया। )

मैं इस try3 समझ में नहीं आता अभी भी => ~ 3sec केंट में फिर से दौड़ना पर रेपो मेरी फाइल के लिए, लेकिन मेरे में रेपो यह 0.300s को फिर से दौड़ना पर (किसी की जरूरत इस डिबग करने के लिए)
संपादित करें: केंट को यह जाँचने वाला होना चाहिए: P

एंटर दबाने से टेस्ट लगभग 200ms में रन हो जाता है।

@rasreddineskandrani क्या आपने इसके विपरीत प्रयास किया? मेरा मतलब है, धीमी रेपो से परीक्षण की नकल करने के लिए तुम्हारा? लेकिन मुझे नहीं लगता कि यह मुद्दा रेपो के साथ है जिसे मैंने पोस्ट किया है। जैसा कि हम स्पष्ट रूप से देख सकते हैं, कई लोग एक ही मुद्दे पर हैं, मैं सिर्फ एक प्रतिलिपि प्रस्तुत करने योग्य उदाहरण पोस्ट कर रहा था।

@kentcdodds क्या आप हमारे नायक एक बार और होंगे?

@SimeonRolev मेरे बेंचमार्क में मैं केंट रेपो में एक ही मुद्दा नहीं देखता। आपके पास केंट रेपो में कुछ है। यह धीमी गति का कारण बनता है => इसके बाहर का भाग तेज होता है।

यह github मुद्दा जेस्ट परफॉर्मेंस विंडो बनाम macOS / लिनक्स से संबंधित है क्योंकि वे एक ही पर नहीं पहुंचे थे। उन्होंने मुझे यह अनुमान नहीं लगाया। (यह अब तक 2 साल पहले jest v23 के साथ बेहतर है)

हैलो, मैं यहाँ एक ही मुद्दे का सामना कर रहा हूँ। मेरे पास एक विंडोज़ मशीन और डब्लूएसएल है। मैंने इस व्यवहार का परीक्षण करने के लिए अपनी परियोजना फाइलों को WSL में कॉपी कर लिया। यहाँ एक ही दो बुनियादी परीक्षणों के रन दिए गए हैं:
विंडोज 10 (संस्करण 2004):

WSL 2 (Ubuntu 20.04):

परीक्षण बहुत सरल हैं:

परियोजना CRA के साथ बनाई गई है, इसलिए सेटिंग्स को बॉट करने के लिए कोई कॉन्फ़िगरेशन नहीं है, मैंने जेस्ट के संदर्भ में कुछ भी नहीं जोड़ा।
मोचा पर समान परीक्षण तेज गति से चलते हैं, लगभग तुरंत। मैं हमारी परियोजना के लिए एक परीक्षण वातावरण स्थापित करने की कोशिश कर रहा हूं, और मैं वास्तव में जेस्ट का उपयोग करना चाहूंगा, लेकिन ऐसा लगता है जैसे मैं अधिक से अधिक परीक्षण जोड़ रहा हूं, परीक्षण सूट धीमा और धीमा होगा। प्रत्येक परीक्षण 0.8 सेकंड जोड़ रहा है, जो हास्यास्पद है, क्योंकि वे कुछ भी नहीं करते हैं। खिड़कियों पर परीक्षण निष्पादन के साथ कुछ गड़बड़ है, और मुझे नहीं पता कि क्या।
समस्या बदतर थी, एक एकल परीक्षण में लगभग 15 सेकंड लगेंगे, लेकिन जब मैंने --runInBand और जोड़ा, तो स्थिति में थोड़ा सुधार हुआ, लेकिन मुझे लगता है कि यह अभी भी पर्याप्त नहीं है, मोचा वॉच मोड तत्काल है।

यार्न संस्करण 1.22.5 है, अन्य सभी एनपीएम निर्भरताएं (जैसे प्रतिक्रिया और प्रतिक्रिया-स्क्रिप्ट) नवीनतम हैं।

मैंने एंटी-वायरस और विंडोज़ डिफेंडर को यह देखने के लिए अक्षम कर दिया कि क्या इसका कोई प्रभाव है, लेकिन यह नहीं है। इसके अलावा, मैंने अपने प्रोजेक्ट फ़ोल्डर के लिए इंडेक्सिंग को अक्षम कर दिया है, जिसका कोई लाभ नहीं है।

संपादित करें: मैंने एंटर दबाने की कोशिश की, और परीक्षण WSL पर उतने ही तेज़ थे:

अब मैं वास्तव में उलझन में हूँ :)

लेकिन यह अभी भी बहुत धीमा लगता है, क्योंकि ऐसा लगता है कि प्रत्येक परीक्षा में 0.3 सेकंड लगते हैं, जो कि बहुत कुछ है, उन्हें देखते हुए कि वे कुछ भी नहीं करते हैं। मुझे उम्मीद है कि यह सूट 0.1 सेकंड के भीतर पूरा हो जाएगा।

संपादित करें 2: जब मैंने अपने परीक्षण सूट में 100 परीक्षण जोड़े, तो उन्हें चलाने के लिए लगभग 44 सेकंड लगे, भले ही मैं चलाने के लिए एंटर दबाऊं:

WSL पर लगभग 9-10 सेकंड में एक ही परीक्षण सूट होता है: