<p>هناك 25 أداء</p>

آسف على الانحدار ولكن

آسف لا يمكن مشاركة قاعدة التعليمات البرمجية الخاصة بنا

يعني أنه لا يمكننا فعل أي شيء على الإطلاق. هذه هي المرة الأولى التي أسمع فيها عن تراجع الأداء ، في كل مكان آخر سمعت فيه أن من 10-40٪ _تحسين_ في الأداء من 24 إلى 25. تحتاج إلى تقديم نوع من إعادة الإنتاج ، وإلا فسيتعين علينا إغلاق هذه المشكلة لأنها ليست قابلة للتنفيذ على الإطلاق كما هي.

إذا كنت تريد أن ترى هذا العنوان ، فستحتاج إلى قضاء بعض الوقت في تجميع حالة تكاثر ، أو تأمل أن يفعل ذلك شخص آخر.

حسنًا ، سأرى ما إذا كان بإمكاني سحب أبطأ 10 اختبارات لدينا ، ثم حاول تشغيلها في 24 مقابل 25. في غضون ذلك ، ما الذي تنصح به فيما يتعلق بمسح ذاكرة التخزين المؤقت قبل إجراء الاختبارات في CI؟ افعلها؟ لا تفعل ذلك؟

التكوين الخاص بك ، خاصة transforms وملفات الإعداد ذات صلة أيضًا

بماذا تنصح فيما يتعلق بمسح ذاكرة التخزين المؤقت قبل إجراء الاختبارات في CI

أنا شخصياً أعتقد أنها فكرة جيدة فقط للتأكد من عدم وجود شيء قديم حول إعطاء سلبيات أو إيجابيات كاذبة. هل يُحدث فرقًا كبيرًا في وقت تشغيل اختباراتك لعدم مسح ذاكرة التخزين المؤقت؟

يبدو أنه أبطأ قليلاً عند تشغيله بعد مسح ذاكرة التخزين المؤقت. شكرًا للنصائح ، سأبحث في الأمر وأرى ما إذا كان بإمكاني محاولة إعادة المحاولة

FWIW ، لقد لاحظت أيضًا أن الإصدار 25 إما أبطأ قليلاً أو على قدم المساواة مع الإصدار 24. لم أر في أي مكان ما يقرب من 10-40٪ تحسن.

لقد رأيت تسريعًا كبيرًا على jest 24 كما هو مذكور هنا: https://github.com/facebook/jest/issues/7811#issuecomment -577057189

تم اختبار ما ورد أعلاه على OSX.

ومع ذلك ، فإن الإعداد نفسه يعمل بشكل أبطأ بكثير على CI الذي يعمل بنظام CentOS.

مشكلة خاصة بـ Linux؟ I / O القضايا ذات الصلة عند كتابة ملفات ذاكرة التخزين المؤقت؟ هل من الممكن إيقاف تشغيل إنشاء ذاكرة التخزين المؤقت تمامًا لاستبعاد ذلك؟

أعتقد أنني وجدت الجاني في حالتنا ، إنه العلم --collectCoverage . عند إزالته لكل من Jest 24 و 25 ، تعمل اختباراتنا تقريبًا أسرع مرتين تحت 25. عند تمكينها ، تكون اختباراتنا الأقل من 25 بطيئة تقريبًا 4 مرات مثل الاختبارات نفسها التي تقل عن 24 عامًا.

هذا قابل للتكرار على كل من OSX و CentOS ، لذلك على عكس تعليقي السابق ، لا تبدو المشكلة خاصة بـ Linux.

مثير للاهتمام! لقد قمنا بتحديث اسطنبول إلى الإصدار 3 ، ربما يكون هناك شيء ما قد تراجع. لقد أضفنا دعمًا لتغطية كود v8 ، لذلك ربما أفسدت عملية إعادة البناء عند القيام بذلك

نعم! هذا يتفق مع ما أراه أيضًا. نحن نعمل مع تغطية في CI حيث تكون أبطأ مرتين. وعندما أركض محليًا بدون covg يكون سريعًا جدًا. SimenB هل هناك أي خيار تكوين لاستخدام اسطنبول الأقدم؟ :)

مرددًا ما قاله csvan ، سيكون من الجيد إيقاف تشغيل إنشاء ذاكرة التخزين المؤقت في CI إذا كان هذا في الواقع

لا يمكنني إعادة إنتاج هذا - المستودعات التي أختبرها لها نفس الأداء تقريبًا مع --coverage بين الإصدارين 24 و v25. هل سيتمكن شخص ما من تكوين مستودع مع jest 24 و jest 25 حيث يظهر التبديل بينهما فرقًا؟

قمت للتو بتشغيل CI build مع تعطيل التغطية ، أعتقد أن csvan يعمل على شيء ما. يتم إجراء الاختبارات في الساعة 4:00 مع إيقاف تشغيل التغطية مقابل 11 دقيقة مع تشغيل التغطية. سأحاول معرفة ما إذا كان بإمكاني إنشاء repro في نهاية هذا الأسبوع في وقت ما.

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 إلى جعل اختباراتنا أبطأ عند استخدام التغطية (166 ثانية مع Jest 24 مقابل 381 ثانية مع Jest 25). مع عرض Jest 25 للعديد من هذه الأخطاء أثناء تشغيل عمليات التحقق:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0xb9c575dbe3d 
13: 0xb9c57ab091a 
14: 0xb9c579e7d65 
15: 0xb9c579ebaf3 

<--- Last few GCs --->

[733:0x102804000]    84639 ms: Mark-sweep 1335.2 (1449.6) -> 1325.4 (1452.1) MB, 1443.2 / 0.0 ms  (average mu = 0.135, current mu = 0.076) allocation failure scavenge might not succeed
[733:0x102804000]    85872 ms: Mark-sweep 1338.3 (1452.1) -> 1327.8 (1455.1) MB, 1159.4 / 0.0 ms  (average mu = 0.101, current mu = 0.059) allocation failure scavenge might not succeed


<--- JS stacktrace --->

يؤدي الرجوع إلى الإصدار Jest 24 إلى اختفاء هذه الأخطاء.

لقد لاحظت أيضًا أن Jest 25 يتعامل مع collectCoverageFrom مختلف حيث يبدو أنه يجمع التغطية من الملفات التي قمنا بتعطيلها صراحة في هذا التكوين. هل تغير دعم بناء جملة glob هناك؟

أي آثار JS على الإطلاق؟ سيكون من المثير أن نرى أين ماتت.

لقد لاحظت أيضًا أن Jest 25 يتعامل مع collectionCoverageFrom بشكل مختلف حيث يبدو أنه يجمع التغطية من الملفات التي قمنا بتعطيلها صراحة في هذا التكوين. هل تغير دعم بناء جملة glob هناك؟

لقد قمنا بالترقية إلى Micromatch 4 ، ربما يكون قد غير شيئًا ما. لا توجد تغييرات عليه عن قصد ، رغم ذلك. هل يمكنك فتح قضية منفصلة مع الاستنساخ؟

أي آثار JS على الإطلاق؟

تمت طباعة هذا:

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x521cca5be3d]
Security context: 0x0ebfa799e6e9 <JSObject>
    1: _clearMemoizedQueries [0xebf2a5aba99] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~208] [pc=0x521cd0d9a4e](this=0x0ebf5bee2aa9 <EventTargetImpl map = 0xebf7963d039>)
    2: _clearMemoizedQueries [0xebf2a5aba99] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-...

تحرير : في الواقع ، أرى أخطاء كومة حتى مع تعطيل التغطية.

لقد قمنا بالترقية إلى Micromatch 4 ، ربما يكون قد غير شيئًا ما. لا توجد تغييرات عليه عن قصد ، رغم ذلك. هل يمكنك فتح قضية منفصلة مع الاستنساخ؟

سوف تفعل.

الرنين مرة أخرى. من المؤكد أن التغطية أبطأ ويبدو أنها زائفة. ها هي توقيتات OSX.

46.69
41.77
45.06

v24 coverage
78.60
75.79
80.38

v25
45.93
52.49
53.36

v25 circus
61.27
52.08

v25 coverage
310.98
227.15
153.81

توقيت ل CI (ترافيس).

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

milesj ما هو سيرك v25؟

إنها مزحة عداء جديد ، والذي من المفترض أن يكون أسرع ، لكنه ليس مما رأيته أبدًا. https://www.npmjs.com/package/jest-circus

EvHaus الآثار من JSDOM مثيرة للاهتمام (قد تكون أيضًا مصادفة تمامًا ، بالطبع). هل يمكنك محاولة تثبيت jest-environment-jsdom@24 واستخدام ذلك؟ لقد قمنا بالترقية من 11 إلى 15 ، لذلك ربما تغير شيء ما هناك. يبدو وكأنه طلقة طويلة ، ولكن من يدري

SimenB استرجاع jest-environment-jsdom إلى <24.0.0 في package.json له تأثير بالتأكيد. اختفت أخطاء heap out of memory ويبدو أن Jest يكمل تشغيله دون أي مشكلة.

مثير للاهتمام! إذا كان لديك الوقت ، فسيكون من الرائع أن تتمكن من الاختبار

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

أو مجرد ربط في jsdom ومنصف. سأفعل ذلك غدًا ، لكن ليس لدي حقًا استنساخ جيد بعد

بالنسبة للاختبارات التالية ، لم يتم تمكين التغطية.

• مع [email protected]
  
  
  
  • 143 ثانية لإجراء الاختبارات
  
  
  • لا توجد مواضيع لا مواضيع
  
  
• مع [email protected]
  
  
  
  • 154 ثانية لإجراء الاختبارات
  
  
  • لا توجد مواضيع لا مواضيع
  
  
• مع [email protected]
  
  
  
  • 228 ثانية لإجراء الاختبارات
  
  
  • العديد من أخطاء JavaScript heap out of memory
  
  

تتبعات المكدس

هذه بعض تتبعات المكدس من تشغيل jest-environment-jsdom-fourteen :

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x20deef6dbe3d]
Security context: 0x36ee8219e6e9 <JSObject>
    1: _modified [0x36ee35982ec1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~189] [pc=0x20deefba6433](this=0x36eef3246e99 <EventTargetImpl map = 0x36ee99264ee9>)
    2: _insert [0x36eeb41f1e41] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourte...

    0: ExitFrame [pc: 0x2aa5df5be3d]
Security context: 0x116a8d49e6e9 <JSObject>
    1: _clearMemoizedQueries [0x116a365133d1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~208] [pc=0x2aa5dfe7dae](this=0x116a8f16cd11 <EventTargetImpl map = 0x116ae7cc9b61>)
    2: _clearMemoizedQueries [0x116a365133d1] [/Users/evhaus/Git/zenhub/client/node_modules/jest-...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x20deef6dbe3d 
13: 0x20deefba6433 

    0: ExitFrame [pc: 0xb8909f5be3d]
Security context: 0x09e628d9e6e9 <JSObject>
    1: childrenIterator [0x9e612e1d581] [/Users/evhaus/Git/zenhub/client/node_modules/symbol-tree/lib/SymbolTree.js:~367] [pc=0xb890a41010e](this=0x09e612e3eb01 <SymbolTree map = 0x9e6a7f56c09>,parent=0x09e685ca27d1 <EventTargetImpl map = 0x9e6061f36f1>,options=0x09e67b6026f1 <undefined>)
    2: arguments adaptor frame: 1->2
    3: _detach [0x9e65c4ae341] [/U...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0x2aa5df5be3d 

    0: ExitFrame [pc: 0x180d6e95be3d]
Security context: 0x02052079e6e9 <JSObject>
    1: _modified [0x205b86c1861] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~189] [pc=0x180d6ede24fa](this=0x0205c8284411 <EventTargetImpl map = 0x205c1ea9769>)
    2: _attrModified [0x205b86ba771] [/Users/evhaus/Git/zenhub/client/node_modules/jest-environment-jsdom-fou...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d041 node::Abort() [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 2: 0x10003d24b node::OnFatalError(char const*, char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 3: 0x1001b8e25 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 4: 0x100586d82 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 5: 0x100589855 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 6: 0x1005856ff v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 7: 0x1005838d4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 8: 0x10059016c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
 9: 0x1005901ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
10: 0x10055fb34 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
11: 0x1007e7e14 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/evhaus/.nvm/versions/node/v10.17.0/bin/node]
12: 0xb8909f5be3d 

أتمنى أن يساعدك هذا

لا أعرف ما إذا كان هذا سيساعد ، لكن منظمتي شهدت تباطؤًا هائلاً من Jest 24 إلى Jest 25 (18 دقيقة إلى 28 دقيقة) التي اختفت بعد إيقاف جمع التغطية (حتى 10 دقائق).

rosasynstylae بدافع الفضول ، هل

benmonro إنه كذلك ، نعم.

وكذلك الحال بالنسبة لنا! SimenB هل تعتقد أن الكثير من اللقطات في الريبو يمكن أن تسبب هذا؟

نواجه مشكلات في الأداء بدون لقطات. نحن نجمع التغطية بالرغم من ذلك. تباطؤ كبير من 24 -> 25. 2 مشروع مختلف. وهي تختلف ولكن التباطؤ كبير ومتسق.

يمكنني إجراء الاختبارات مرارًا وتكرارًا دون أي تغييرات وتكون الاختبارات أبطأ 10 مرات في المتوسط ​​ثم كانت بـ 24.

أعود إلى الرقم 24 وعادت عمليات التشغيل إلى السرعة التي اعتدنا عليها.

يمكنني تقديم المزيد من المعلومات إذا لزم الأمر. أردت التأكد من ذكر مشروعين بدون اختبارات لقطة.

من كل التعليقات هنا ، يبدو بالتأكيد أن التغطية هي المشكلة ، وربما تراجعًا في اسطنبول؟

من كل التعليقات هنا ، يبدو بالتأكيد أن التغطية هي المشكلة ، وربما تراجعًا في اسطنبول؟

لن أكون سريعًا جدًا لتوجيه أصابع الاتهام إلى اسطنبول. في حالتي ، حتى مع تعطيل التغطية ، أرى مشكلات كبيرة في الأداء والاستقرار في Jest 25. راجع https://github.com/facebook/jest/issues/9457#issuecomment -579423330

من الممكن أن تكون هناك مشكلتان منفصلتان:

1) مشاكل مع jest-environment-jsdom-fourteen و
2) مشاكل متعلقة بتغطية اسطنبول

لقد خفضت تصنيف micromatch إلى ^3.0.0 ورأيت تسريعًا هائلاً باستخدام --coverage ، يعود أكثر أو أقل إلى الأداء الذي رأيناه في Jest 24. هل يمكن لأي شخص التكاثر؟

تحديث: ومع ذلك ، فإن التشغيل الآن بدون --coverage يعود أيضًا إلى Jest 24 من مستويات الأداء - ضعف البطء: - /

EvHaus شكرا للتحقق ، مثيرة جدا للاهتمام! ما زلت غير قادر على إعادة إنتاج هذا ، للأسف. لذا فإن الاستنساخ سيظل رائعًا ، وبهذه الطريقة يمكنني محاولة تصحيح هذا.

لقد خفضت تصنيف micromatch إلى ^3.0.0 ورأيت تسريعًا هائلاً باستخدام --coverage ، يعود أكثر أو أقل إلى الأداء الذي رأيناه في Jest 24. هل يمكن لأي شخص التكاثر؟

تحديث: ومع ذلك ، فإن التشغيل الآن بدون --coverage يعود أيضًا إلى Jest 24 من مستويات الأداء - ضعف البطء: - /

ماذا يحدث في العالم ... بقدر ما لا أرى أي شيء في اسطنبول يعتمد على micromatch ، فلماذا يجب أن تؤثر على التغطية أبعد مني

أصبح أداء الميكروماتش كله سخيفًا بعض الشيء ، مع تغطية v3 أسرع من v4 ، بدون v4 أسرع من v3؟ 😅

SimenB نعم ، قم

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

إلى الحزمة الخاصة بنا ، حلق json 6 دقائق من التشغيل عند استخدام --coverage ، مما أعادها تقريبًا إلى ما رأيناه في Jest 24.

بقدر ما لا أرى أي شيء في اسطنبول يعتمد على micromatch

تم العثور على هذا التعليق في موضوع آخر قد يكون ذا صلة بهذا:

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

تأكدت للتو من عدم وجود شيء في اسطنبول يسحب micromatch (يستخدمون minimatch في البرنامج المساعد babel).

قد يكون هناك شيء يتعلق بالاستثناءات لا تعمل بشكل صحيح ، بالتأكيد. نستخدمه للتحقق مما يجب أن نستخدمه: https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. هل يمكنك التمسك ببعض عمليات تسجيل الدخول هناك ومعرفة ما إذا كنا نعيد true أي مكان بـ micromatch@4 الذي لم نقم به مقابل micromatch@3 ؟

بالتأكيد يبدو الأمر وكأنه مشكلتان منفصلتان ، واحدة عن jsdom والأخرى حول التغطية

يمكنني أن أؤكد أنه عاد إلى السرعة الطبيعية بالنسبة لنا في CI عندما نحل micromatch @ 3 أيضًا.

Jest + مطبوعة نصية + تفاعل هنا. يبدو أن رؤية هذه المشكلة واستخدام قرارات القوة npm لفرض micromatch ^ 3.0.0 يعمل على إصلاح التباطؤ الجنوني.

هل لديك أنماط تغطية خاصة لأنماط ملفات الاختبار في التكوين الخاص بك؟

EvHaus أنا مهتم جدًا إذا رأيت فرقًا عن طريق خفض تصنيف Micromatch أيضًا ، ورأيت كما رأيت فرقًا كبيرًا في إصدارات jsdom

إذا كان هذا ما تعنيه ، إذن نعم.

  collectCoverage: true,
  collectCoverageFrom: [
    'src/**/*.ts',
    'src/**/*.tsx',
    'src/**/*.js',
    'src/**/*.jsx',
    '!src/themes/**',
    '!src/**/Styled*.tsx',
    '!src/**/Styled*.ts',
    '!src/**/*Actions.ts',
    '!src/mainStore.ts',
    '!src/App.tsx',
    '!src/AppView.tsx',
    '!src/AppError.tsx',
    '!src/StyledAppComponents.tsx',
    '!src/index.tsx',
    'src/utility/redux/*.ts',
    '!src/testingUtils/*',
    '!src/**/index.ts',
    '!docs/**/**',
  ],

لدينا هذا أيضًا ويبدو لنا متشابهًا تمامًا في الطول / القيم

@ Ancient123 نعم ، بالضبط. يبدو مرتبطًا بانحدار Micromatch للأنماط السلبية. شكرا!

يبدو مرتبطًا بانحدار Micromatch للأنماط السلبية. شكرا!

لاحظت ، سأنظر في الأمر في أسرع وقت ممكن.

شيء أداء الميكروماتش كله أصبح سخيفًا بعض الشيء

آسف على تدهور الأداء. إنشاء تعبيرات منتظمة من أجل globbing هو أصعب بكثير مما يبدو. خاصة عندما تحتاج إلى التعامل مع النفي وأن تكون مشتركة بين الأنظمة الأساسية. أنا أبحث في هذا الآن.

jonschlinkert لم يكن المقصود منه

نعم! ماذا قال SimenB . لا شيء سوى ❤️

EvHaus أنا مهتم جدًا إذا رأيت فرقًا عن طريق خفض تصنيف Micromatch أيضًا ، ورأيت كما رأيت فرقًا كبيرًا في إصدارات jsdom

في package.json قمت بتعيينه:

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

أعد تشغيل npm install ، ثم حذف node_modules/jest/micromatch يدويًا (الذي كان في الإصدار 4). ثم أعد إجراء اختباراتي.

لسوء الحظ ، ما زلت أرى العديد من أخطاء "نفاد الذاكرة في JavaScript".

هل أقوم بالرجوع إلى إصدار سابق بشكل صحيح؟

resolutions يحتاج yarn ، npm لم ينفذه بعد (إنه على خريطة الطريق للإصدار 7: https://blog.npmjs.org/post/186983646370/npm- cli-roadmap-صيف -2019)

EvHaus حتى يخرج npm v7 ، يمكنك استخدام الدقة في npm مع هذه الحزمة: https://www.npmjs.com/package/npm-force-resolutions

آسف للتأخير. تم استخدام npm-force-resolutions (الذي يقوم بالشيء الصحيح) لقفل micromatch في الإصدار 3. لسوء الحظ ، لم يجعل أخطاء الكومة الخاصة بي تختفي.

بالنسبة لي ، لا يزال اللوم [email protected] ، كما هو مذكور هنا: https://github.com/facebook/jest/issues/9457#issuecomment -579423330

حل jsdom إلى thirteen هو ما يصلحه.

هل يعاني أي شخص عانى من تدهور في الأداء في 25 لديه مشكلات لم يتم إصلاحها إما باستخدام jsdom @ 13 أو micromatch @ 3؟ يتم إصلاح تسرب الذاكرة في JSDOM (https://github.com/jsdom/jsdom/pull/2840 والعديد من المشكلات / العلاقات العامة المرتبطة به) وتم الإبلاغ عن الانحدار في micromatch ويتم العمل عليه: https: // github.com/micromatch/micromatch/issues/179.

تم إطلاق الإصدار الثابت من JSDOM ، يمكنك استخدامه عن طريق تثبيت jest-environment-jsdom-sixteen . EvHaus هل يمكنك التحقق من أنه يعمل على إصلاح مشكلتك؟

SimenB من المحتمل أن jest-environment-jsdom-sixteen مقابل استخدام الافتراضي ، وشهدت زيادة 20 ثانية في وقت تشغيل نفس مجموعة الاختبار على عمليات التشغيل المتكررة.

الإفراط في استخدام الإصدار 15 (وهو ما يأتي مع المزاح افتراضيًا) ولا توجد تغييرات أخرى؟ هل يمكنك الاختبار مع 16.1.0 أيضًا (على الرغم من أن هذا يؤدي إلى تسرب الذاكرة ، فقد يكون اختباره أصعب). لقد هبطت JSDOM للتو مع دعم عنصر مخصص ، فربما يكون هناك بعض الانحدار هناك؟ لست متأكدا

تم إطلاق الإصدار الثابت من JSDOM ، يمكنك استخدامه عن طريق تثبيت jest-environment-jsdom-sixteen. EvHaus هل يمكنك التحقق من أنه يعمل على إصلاح مشكلتك؟

لسوء الحظ ، لا تزال تظهر أخطاء الكومة مع jest-environment-jsdom-sixteen . آخر إصدار عمل مستقر من JSDom بالنسبة لي هو jest-environment-jsdom-thirteen .

تم إطلاق الإصدار الثابت من JSDOM ، يمكنك استخدامه عن طريق تثبيت jest-environment-jsdom-sixteen . EvHaus هل يمكنك التحقق من أنه يعمل على إصلاح مشكلتك؟

تعمل البيئة مع قاعدة التعليمات البرمجية الخاصة بنا ، لكننا ما زلنا نشهد تراجعًا بنسبة 100٪ تقريبًا في وقت التشغيل. يبدو أن jest-environment-jsdom-sixteen يحسن أداء وقت التشغيل بنسبة 10٪ فقط عند استخدام 25.1 مقابل 24.9

مرحبًا SimenB ،

لقد صنعت الحالة القابلة لإعادة الإنتاج هنا 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 |

في حالتنا ، حيث كان الإصدار 25.1 من jest أبطأ بنسبة 50٪ تقريبًا مقارنةً بالإصدار 24.9 ، أصبح الإصدار الأخير v25.2.0 أبطأ بنسبة 20٪ مقارنةً بالإصدار 25.1 🙈

olebedev Woah ، هذا مؤلم 😬

أنا أحصل على أرقام مماثلة لك. إذا كان يعتمد على مشروع حقيقي ، فإنني أوصي باستخدام تغطية v8. يستغرق وقت التشغيل من 600 إلى 35 ثانية على جهازي في عملية الاستنساخ. ربما يكون سبب الاختلاف الضخم هو أننا لا نحاول استخدام ملفات غير مغطاة بتغطية v8 (نقول فقط أنه تم الكشف عن كل بايت ، وهو ما يعمل مع الإصدار 8).

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

لست متأكدًا من سبب البطء الشديد ... سأحاول أن أجد بعض الوقت للنظر فيه (لن يكون ذلك قريبًا في أي وقت). يجب ألا يكون على الأقل أبطأ في الإصدار 25 من الإصدار 24

هل أفهم المستندات بشكل صحيح أنه يمكننا استخدام تغطية v8 معًا
مع البيئة ...-sixteen ؟

هتافات،
ي

في الأربعاء ، 8 أبريل 2020 ، الساعة 22:33 ، كتب Simen Bekkhus ، [email protected] :

olebedev https://github.com/olebedev Woah ، هذا مؤلم 😬

أنا أحصل على أرقام مماثلة لك. إذا كان يعتمد على مشروع حقيقي أنا
نوصي باستخدام تغطية v8. يستغرق وقت التشغيل من 600 إلى 35 ثانية على جهاز
آلة في الاستنساخ الخاص بك. ربما يكون سبب الاختلاف الهائل هو ذلك
لا نحاول تجهيز الملفات غير المغطاة بتغطية v8.

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

لست متأكدًا من سبب البطء الشديد ... سأحاول أن أجد بعض الوقت للنظر فيه.
يجب ألا يكون على الأقل أبطأ في الإصدار 25 من الإصدار 24

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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.

(لقد اختبرت هذا من قبل مع Node env ، ولكن إذا لم يعمل مع jsdom env فهذا خطأ - يرجى فتح مشكلة منفصلة 🙂)

jest-environment-jsdom-sixteen + v8 حيث كان مزود التغطية أسوأ بنحو 20٪ بالنسبة لنا على jest 25.3.0 ، العقدة 12.16. نحاول أيضًا تصحيح سبب تدهور أداء الاختبار بنسبة 80 ٪ تقريبًا من 24 إلى 25.

joual هل جربت حل micromatch (الرجوع إلى 3.x)؟

من خلال تجربة مماثلة هنا ، تتضاعف أوقات الاختبار (_ بدون تغطية) على الإصدار 25 من 35-40 ثانية إلى 80-90 وأحيانًا أكثر. حاولت قفل micromatch على الإصدار 3 ، ولم يكن هناك فرق ملموس. Fwiw ، لدينا حوالي 3 آلاف اختبار ، منها 58 اختبارًا سريعًا.
تمت محاولة الرجوع إلى إصدار أقدم من jsdom ولكن يبدو أن هذا قد أدى إلى حدوث الكثير من اختبار الكسر بسبب الميزات الحديثة التي كنا نستخدمها. سأرى ما إذا كان بإمكاني الالتفاف حول هذا بطريقة أو بأخرى وتقديم تقرير.

SimenB تغطية وظيفة في مشروع أجمل هو أيضا بطيئة جدا ، هل يمكنك التحقق من ذلك؟ https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest يجمع التغطية ، وظيفة أخرى لا تفعل ذلك.

من خلال تجربة مماثلة هنا ، تتضاعف أوقات الاختبار (_ بدون تغطية) على الإصدار 25 من 35-40 ثانية إلى 80-90 وأحيانًا أكثر. حاولت قفل micromatch على الإصدار 3 ، ولم يكن هناك فرق ملموس. Fwiw ، لدينا حوالي 3 آلاف اختبار ، منها 58 اختبارًا سريعًا.
تمت محاولة الرجوع إلى إصدار أقدم من jsdom ولكن يبدو أن هذا قد أدى إلى حدوث الكثير من اختبار الكسر بسبب الميزات الحديثة التي كنا نستخدمها. سأرى ما إذا كان بإمكاني الالتفاف حول هذا بطريقة أو بأخرى وتقديم تقرير.

تم تجربة إصدارات مختلفة من jsdom اليوم على jest @ 24 (وهو الإصدار 11 افتراضيًا). حتى الإصدار 14 ، يبدو أن كل شيء يعمل بشكل جيد ، ولكن اعتبارًا من الإصدار 15 ، تستغرق عمليات التشغيل الاختبارية وقتًا أطول بنسبة 50-60٪ باستمرار. نفس القصة في الإصدار 16. سأرى ما إذا كان بإمكاني الحصول على أداء مماثل في المزحة @ 25 عن طريق خفض تصنيف jsdom إلى الإصدار 14.

[email protected] به بعض إصلاحات الذاكرة ، EvHaus هل يمكنك تجربته؟ عثر Jest الخاص بـ --detect-leaks تسريبات في الإصدارات السابقة ، ولكن ليس في 16.2.2.

لقد حصلت أيضًا على بعض التحسينات الأخرى إذا كان لديك الكثير من الروابط الرمزية (وهي بطيئة جدًا على النوافذ) ، لذلك إذا كان بإمكان الأشخاص تجربة [email protected] فسيكون ذلك رائعًا 🙂

SimenB ما أسهل طريقة لاختبار ذلك؟ إذا أضفت [email protected] مباشرة بصفتك أداة devDependency تتجاهل Jest ذلك وتستخدم كل ما هو مجمّع مع jest-environment-jsdom وهو 15.2.1 اليوم.

كيف يمكنني خداع npm للتأكد من أنه يستخدم إصدار jsdom الذي أريده؟

قم بتثبيت jest-environment-jsdom-sixteen واستخدامه https://jestjs.io/docs/en/configuration#testenvironment -string

تم نشر Alpha ، لذا يمكنك تجربة 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]>,...

سيء جدا 😞 هل هذا مع أو بدون تغطية؟

كان ذلك بدون تغطية. يجب أن أوضح.

هل تعتقد أنني أقوم بتشغيل إصدار قديم إلى حد ما من Node (v10) سيكون عاملاً في هذا؟

يمكنك تجربة استخدام إصدارات أحدث ، إذا لم يكن هناك شيء آخر ، فستكون نقطة بيانات مثيرة للاهتمام. الأشياء الأخرى التي يجب تجربتها هي محاولة تفريغ كومة قبل أن تموت مباشرة. ماذا يوجد في الكومة؟

من المثير للاهتمام أنه لم يذكر أحد أن micromatch @ 4 لم يعد https://github.com/micromatch/micromatch/pull/151 و https://github.com/facebook/jest/pull/10131 يقدم مفقودًا التخزين المؤقت على جانب الدعابة.

بالنسبة لي ، فإن الرجوع إلى إصدار سابق إلى jest-environment-jsdom-sixteen وفّر 50٪ من الوقت.
ولكن مع jest 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 على خط أنابيب Bitbucket. لقد لاحظت أيضًا أن البطء يزداد مع تمكين التغطية. الإصدار 25 يزداد سوءًا مقارنة بالإصدار 26 ويتعطل خط الأنابيب بسبب استهلاك الذاكرة.

SimenB قمت بعمل git bisect لاكتشاف أين تم تقديم تراجع الأداء بين 24.9 و 25.1. لقد استخدمت أجمل الاختبارات لأنها تعمل بدون تعديل على طول الطريق من 24.9 إلى 26.1.

قارنت وقت التشغيل المتراكم لثلاثة عمليات تشغيل للمجموعة الفرعية js (بآمان بعض الوقت) مع ذاكرة التخزين المؤقت المعطلة. وبشكل أكثر تحديدًا ، كان الأمر الذي أستخدمه هو ( yarn run jest --no-cache tests/js/ ) مع العقدة 10.19. لأن العقدة 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 من ad5377333daf6716af3465bba39f86b7db485e2b الذي أعاد الأداء.

بالنظر إلى 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. أنا متأكد من أن هذا ليس هو الحل ، لكن على الأقل لدينا شيء نعمل به.

كنقطة بيانات أخرى ، تستغرق مجموعة المرح الخاصة بنا حاليًا حوالي 2767 ثانية مع [email protected] وفي 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). هل يمكنك تأكيد؟

يبدو هذا عنق الزجاجة غريبًا على الرغم من ذلك - تحولت Node نفسها إلى استخدامه منذ 18 شهرًا: https://github.com/nodejs/node/pull/21573. لذلك من المحتمل أن يكون هذا شيئًا غريبًا نقوم به من جانبنا. على الرغم من ذلك ، فإن https://github.com/nodejs/node/issues/26229 المرتبط مثير جدًا للاهتمام - ربما نحتاج إلى المزيد من التخزين المؤقت من جانبنا؟

SimenB لقد جربت للتو شيئًا مشابهًا لتلك

اضطررت إلى إجراء MyNodeEnv.prototype.getVmContext = null; ، على الرغم من ذلك ، لأنني أختبر مع jest 26 ، ويبدو أنه يتحقق من if (typeof this._environment.getVmContext === 'function') { الآن . لست متأكدًا مما إذا كان هذا قد يتسبب في مشكلات أخرى.

هذه هي النتائج التي أراها بعد عدة جولات:

Jest 26 w / test البيئة: "العقدة" => ~ 280 ثانية
Jest 26 w / بيئة اختبار مخصصة => ~ 210 ثانية
نكتة 24 => ~ 160 ثانية

اسمحوا لي أن أعرف ما إذا كان بإمكاني المساعدة في أي معلومات أخرى أو أي شيء آخر!

كما هو متوقع ، ينتج محرك البيئة المخصص عن نفس التسريع للأجمل.

لقد جربته أيضًا على قاعدة الشفرة الخاصة بنا حيث يكون الاختلاف ~ 270 ثانية مقابل 200 ثانية لذلك فقط حوالي 25٪ وليس 40٪ تخفيض. لسوء الحظ ، لا يمكنني إجراء اختباراتنا مع jest 24 لأننا نعتمد على أجهزة ضبط الوقت الحديثة الجديدة التي تسخر.

فاتني delete في المثال أعلاه ، آسف لذلك.

أتساءل عما إذا كان يكفي تخزين الوظائف المترجمة يدويًا مؤقتًا - هل يمكنك محاولة تطبيق هذا التصحيح؟ (تم تضمين كل من JS المنقولة ومصدر TS هنا)

diff --git i/packages/jest-runtime/build/index.js w/packages/jest-runtime/build/index.js
index 1d094a6dc0..f6d059caa3 100644
--- i/packages/jest-runtime/build/index.js
+++ w/packages/jest-runtime/build/index.js
@@ -267,6 +267,7 @@ const getModuleNameMapper = config => {
 const unmockRegExpCache = new WeakMap();
 const EVAL_RESULT_VARIABLE = 'Object.<anonymous>';
 const runtimeSupportsVmModules = typeof _vm().SyntheticModule === 'function';
+const compiledFunctionCache = new Map();
 /* eslint-disable-next-line no-redeclare */

 class Runtime {
@@ -1169,23 +1170,30 @@ class Runtime {
       value: this._createRequireImplementation(localModule, options)
     });
     const transformedCode = this.transformFile(filename, options);
-    let compiledFunction = null; // Use this if available instead of deprecated `JestEnvironment.runScript`
+    let compiledFunction = undefined; // Use this if available instead of deprecated `JestEnvironment.runScript`

     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = (0, _vm().compileFunction)(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
-              filename,
-              parsingContext: vmContext
-            }
-          );
-        } catch (e) {
-          throw (0, _transform().handlePotentialSyntaxError)(e);
+        const params = this.constructInjectedModuleParameters();
+        const cacheKey = transformedCode + params;
+        compiledFunction = compiledFunctionCache.get(cacheKey);
+
+        if (!compiledFunction) {
+          try {
+            compiledFunction = (0, _vm().compileFunction)(
+              transformedCode,
+              params,
+              {
+                filename,
+                parsingContext: vmContext
+              }
+            );
+            compiledFunctionCache.set(cacheKey, compiledFunction);
+          } catch (e) {
+            throw (0, _transform().handlePotentialSyntaxError)(e);
+          }
         }
       }
     } else {
@@ -1194,13 +1202,13 @@ class Runtime {
       const runScript = this._environment.runScript(script);

       if (runScript === null) {
-        compiledFunction = null;
+        compiledFunction = undefined;
       } else {
         compiledFunction = runScript[EVAL_RESULT_VARIABLE];
       }
     }

-    if (compiledFunction === null) {
+    if (!compiledFunction) {
       this._logFormattedReferenceError(
         'You are trying to `import` a file after the Jest environment has been torn down.'
       );
diff --git i/packages/jest-runtime/src/index.ts w/packages/jest-runtime/src/index.ts
index 522adabd1e..8958a4cef8 100644
--- i/packages/jest-runtime/src/index.ts
+++ w/packages/jest-runtime/src/index.ts
@@ -137,6 +137,8 @@ type RunScriptEvalResult = {[EVAL_RESULT_VARIABLE]: ModuleWrapper};

 const runtimeSupportsVmModules = typeof SyntheticModule === 'function';

+const compiledFunctionCache = new Map<string, ModuleWrapper>();
+
 /* eslint-disable-next-line no-redeclare */
 class Runtime {
   private _cacheFS: StringMap;
@@ -1000,24 +1002,29 @@ class Runtime {

     const transformedCode = this.transformFile(filename, options);

-    let compiledFunction: ModuleWrapper | null = null;
+    let compiledFunction: ModuleWrapper | undefined = undefined;

     // Use this if available instead of deprecated `JestEnvironment.runScript`
     if (typeof this._environment.getVmContext === 'function') {
       const vmContext = this._environment.getVmContext();

       if (vmContext) {
-        try {
-          compiledFunction = compileFunction(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
+        const params = this.constructInjectedModuleParameters();
+
+        const cacheKey = transformedCode + params;
+
+        compiledFunction = compiledFunctionCache.get(cacheKey);
+
+        if (!compiledFunction) {
+          try {
+            compiledFunction = compileFunction(transformedCode, params, {
               filename,
               parsingContext: vmContext,
-            },
-          ) as ModuleWrapper;
-        } catch (e) {
-          throw handlePotentialSyntaxError(e);
+            }) as ModuleWrapper;
+            compiledFunctionCache.set(cacheKey, compiledFunction);
+          } catch (e) {
+            throw handlePotentialSyntaxError(e);
+          }
         }
       }
     } else {
@@ -1028,13 +1035,13 @@ class Runtime {
       );

       if (runScript === null) {
-        compiledFunction = null;
+        compiledFunction = undefined;
       } else {
         compiledFunction = runScript[EVAL_RESULT_VARIABLE];
       }
     }

-    if (compiledFunction === null) {
+    if (!compiledFunction) {
       this._logFormattedReferenceError(
         'You are trying to `import` a file after the Jest environment has been torn down.',
       );

اعتقدت أن هذا قد يفعل الحيلة.

const params = this.constructInjectedModuleParameters();
const cacheKey = transformedCode + params;
const cachedData = compileFunctionCache.get(cacheKey);

try {
  compiledFunction = (0, _vm().compileFunction)(
    transformedCode,
    params,
    {
      filename,
      parsingContext: vmContext,
      cachedData,
      produceCachedData: !cachedData,
    },
  );

  if (compiledFunction.cachedDataProduced) {
    compileFunctionCache.set(cacheKey, compiledFunction.cachedData);
  } 
} catch (e) {
  throw (0, _transform().handlePotentialSyntaxError)(e);
}

إنه يحسن الأداء قليلاً ولكن Script لا يزال أسرع كثيرًا.

جربت التوصية من SimenB : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs ؟ commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

على الرغم من أنه أدى إلى تحسين الأداء قليلاً ، إلا أنه لا يزال أبطأ بكثير مما كان عليه في jest 24.x:

• 24.x.Jest: إجمالي وقت تشغيل اختبارات الدعابة 2580 ثانية
• 26.x Jest: إجمالي وقت تشغيل اختبارات الدعابة الخاصة بنا 3166 ثانية

leipert هل حاولت بأي حال من الأحوال خفض مستوى بيئة jsdom إلى 14؟

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" في تكوين الدعابة الخاص بك. يبدو أن هذا لا يزال مسؤولاً عن الجزء الأكبر من زيادة المدة بالنسبة لنا (يضيف 40-50٪) ولكنه بدأ يبدو أن هناك العديد من الانحدارات في اللعب.

pleunv مع jest 24.x نحن في jsdom 16 مع jest-environment-jsdom-sixteen ، كان علينا الترقية بسبب بعض المشكلات في اختبار مكونات الويب. لذا فإن التغيير الوحيد الذي نقوم به: jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom ، لذا فإن إصدار jsdom لا يتغير حتى.

تم فتحه https://github.com/nodejs/node/issues/35375 upstream حول المشكلة التي وجدهاwurstbonbon

SimenB هل أنت على علم بأي بدائل مجدية لـ Micromatch؟ ظل هذا الريبو صامتًا منذ أكثر من نصف عام حتى الآن ، ولا تزال القضايا الرئيسية التي تؤثر على Jest مثل https://github.com/micromatch/micromatch/issues/179 مفتوحة.

ليس حقًا ، هذا ما تستخدمه معظم المكتبات. يمكن أن ننظر إلى minimatch على سبيل المثال ، لكنني أشك في أنه سيكون قابلاً للتطبيق

SimenB ما الذي يجعل Micromatch أفضل من جميع البدائل؟

بناءً على التعليقات الواردة في المشكلة التي فتحتها ، أعتقد أنه يجب علينا العودة إلى استخدام Script في الوقت الحالي حيث يبدو أنه سيحتاج إلى القليل من العمل في Node لإصلاحه هناك.

leipertwurstbonbon أو أي شخص آخر، يمكنك أن تجرب هذا التصحيح في حياتك 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 ...

شكراCellule! هذا جيد بما يكفي بالنسبة لي - سأضع العلاقات العامة عندما يكون لدي بعض الوقت

فريق عمل رائع! هذا يترك فقط مشكلة Micromatch بعد ذلك ، ونأمل أن يخضع الريبو للصيانة النشطة مرة أخرى.

راجع للشغل ، هناك أيضًا انحدار أداء في JSDOM الذي أفترضه. كما فعلت مثل هذه الاختبارات في مشروع ويب كبير. لم يتم تطبيق التصحيحات المذكورة أعلاه.
وبدا الأمر كذلك.

Jest 24  (testEnvironment: "jsdom") (no rewires latest CRA)
144.014s

Jest 24 (testEnvironment: "jest-environment-jsdom-sixteen") (rewire latest CRA that changes testEnvironment)
409.473s (also few failed tests)

Jest 26 (testEnvironment: "jsdom") (no rewires latest CRA) so old jsdom? Whatever is the default for Jest 26 I assume? (I used react-app-rewired to rewire jest config and pnpmfile.js to override what version of Jest was installed with `react-scripts` as it still ships Jest 24 (like resolutions in yarn))
310.275s

Jest 26 (testEnvironment: "jest-environment-jsdom-sixteen") (rewire latest CRA that changes testEnvironment + pnpmfile.js)
over 1200s+ (some tests failed plus test run just stuck forever)

بالتأكيد هذا تقرير أداء غامض للغاية وغير مستقر يجب أن أبقى ، لكنني أعتقد أن كل مدخلات تساعد :)

https://github.com/facebook/jest/releases/tag/v26.5.0 يحتوي على تغيير vm.Script تمت مناقشته هنا

(تحرير: تم التحديث بعد عمليات التشغيل الإضافية)

النتائج الأولية على نفس مجموعة الاختبار:

الدعابة 26.5.2 تحديث
بارد: 59.992
ساخن: 43.976.0000

جيست 26.4:
بارد: 90.213
ساخن: 47.408.0000

تسريع كبير جدًا في الدورات الباردة <3

وإليك النتائج مع مجموعة الاختبار الخاصة بي:

الدعابة 26.5.2 تحديث
بارد: 149 ثانية

Jest 26.4.2 تحديث
بارد: 226 ثانية

أخبار سارة 🙂 أعتقد أننا عدنا إلى انحدار الميكروماتش فقط ، إذن

إذا كنتم تستخدمون npm-force-resolutions لتثبيت micromatch 3. فقد لا تعمل في [email protected]

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

خطأ عند تشغيل الاختبار:

TypeError: _micromatch(...).default.scan is not a function
    at globs.map.glob (/home/travis/build/removed/node_modules/jest-util/build/globsToMatcher.js:65:47)
    at Array.map (<anonymous>)
    at globsToMatcher (/home/travis/build/removed/node_modules/jest-util/build/globsToMatcher.js:61:26)
    at new SearchSource (/home/travis/build/removed/node_modules/@jest/core/build/SearchSource.js:197:49)
    at contexts.map.context (/home/travis/build/removed/node_modules/@jest/core/build/runJest.js:265:16)
    at Array.map (<anonymous>)
    at runJest (/home/travis/build/removed/node_modules/@jest/core/build/runJest.js:264:34)
    at startRun (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:479:35)
    at runWithoutWatch (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:494:10)
    at _run10000 (/home/travis/build/removed/node_modules/@jest/core/build/cli/index.js:416:13)
npm ERR! Test failed.  See above for more details.

SimenB شكرا جزيلا على التحديث. يوفر لنا 20٪ من وقت التشغيل على Travis بعد التحديث إلى [email protected]

نتائجنا:

إنه v26.5

• 323.98 ثانية
• 321.24 ثانية

إنه v24.9

• 262.17 ثانية
• 275.96 ثانية

شكرا SimenB! هذا مذهل. نتائجنا ~ 22000 اختبار في ~ 2000 جناح:

• دعابة 24.x: 2864 ثانية
• جيست 26.5.2: 2967 ثانية

وهو أبطأ بنحو 3٪ وبالتالي في هامش الخطأ ، مقارنةً بالتباطؤ البالغ 27٪ الذي رأيناه من قبل. شكرًا لك ، الآن نحتاج فقط إلى الدمج: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

أردت فقط ملاحظة أن جميع مشكلات "نفاد الذاكرة" التي كنت أواجهها من قبل قد ولت بعد الترقية إلى Jest 26.5.2 و Node 14 (كانت موجودة في Node 10 من قبل). لست متأكدًا من مقدار المشكلة التي نتجت عن Jest vs. بواسطة Node ، ولكن إذا كان الآخرون يواجهون مشكلات مماثلة ، فحاول الترقية إلى كليهما.

تحديث : لا تهتم. لقد بدأت في تلقي أخطاء OOM مرة أخرى. أعتقد أنه يقع مباشرة على الخط الحدودي لما يمكن لجهاز الكمبيوتر المحمول الخاص بي التعامل معه وكانت عمليات التشغيل القليلة الأولى جيدة ، لكنها الآن تموت مرة أخرى. سيتعين عليك الاستمرار في الالتزام بـ 24.xx :(

إذا كان شخص ما مهتمًا ، فقد قمت بإنشاء DOM يتميز بأداء جيد جدًا مقارنةً بـ JSDOM. لديها دعم Jest.

| العملية | JSDOM | DOM سعيد |
| ------------------------------------ | ------- | --------- |
| استيراد / طلب | 333 مللي ثانية | 45 مللي ثانية |
| تحليل HTML | 256 مللي ثانية | 26 مللي ثانية |
| تسلسل HTML | 65 مللي ثانية | 8 مللي ثانية |
| تقديم عنصر مخصص | 214 مللي ثانية | 19 مللي ثانية |
| querySelectorAll ('tagname') | 4.9 مللي ثانية | 0.7 مللي ثانية |
| querySelectorAll ('. فئة') | 6.4 مللي ثانية | 3.7 مللي ثانية |
| querySelectorAll ('[سمة]') | 4.0 مللي | 1.7 مللي ثانية |
| querySelectorAll ('[class ~ = "name"]') | 5.5 مللي ثانية | 2.9 مللي ثانية |
| querySelectorAll (': nth-child (2n + 1)') | 10.4 مللي ثانية | 3.8 مللي ثانية |

ارتباط بالمشروع:
https://github.com/capricorn86/happy-dom/

@ capricorn86 تبدو لطيفة. هل هو متوافق مع المواصفات؟

@ capricorn86 تبدو لطيفة. هل هو متوافق مع المواصفات؟

شكرا لك milesj!

تم تنفيذ الوظيفة التي تم تنفيذها وفقًا للمواصفات ، ولكن لا توجد نظرة عامة مفصلة على المواصفات التي تم تناولها حتى الآن. أنا أفكر في إضافة ذلك. ومع ذلك ، يتم تغطية جميع الوظائف من خلال اختبارات الوحدة.

كان الهدف الأولي لـ DOM هو أن تكون قادرًا على تقديم جانب خادم مكونات الويب بأداء جيد ، حيث كنت بحاجة إليه في بعض المشاريع الأخرى.

FWIW ، لقد حاولت للتو رفع مشروعنا من react-scripts@3 مع Jest 24.9 ، إلى @react-scripts@4 مع Jest 26.6.

تم تنفيذ مجموعة اختبار API للخادم الخاصة بنا سابقًا في حوالي 180-190 ثانية. بعد التبديل إلى Jest 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 تأتي مع Jest كاعتماد.

ليس لدي مربع العمل الخاص بي أمامي ، لذا لا يمكنني الآن أن أتذكر ما إذا كنت أعني بالفعل micromatch أو إذا ركزت حقًا على اسم الحزمة الخطأ هناك :) سأضطر إلى البحث في ذلك مرة أخرى الأسبوع المقبل.

لقد لاحظت للتو أن الإصدار v26 يعمل _ كثيرًا _ أبطأ في iTerm مما هو عليه في المحطة الافتراضية لـ macOS. في مجموعة مكونة من 6500 اختبار ، أحصل دائمًا على النتائج التالية:

• الإصدار 24 ، المحطة الطرفية: ~ 90 ثانية
• الإصدار 24 ، iTerm2: ~ 90 ثانية
• الإصدار 26 ، المحطة الطرفية: ~ 110 ثانية
• الإصدار 26 ، iTerm2: ~ 150 ثانية

لقد فجر هذا ذهني قليلاً بعد شهور من محاولة أشياء مختلفة لفرز التباطؤ. هل هناك أي فرصة لأي شخص آخر لديه مشكلات تتعلق بالأداء على جهاز Mac لتجربة ذلك؟ ضع في اعتبارك ، هذا مع الإصدار 26 .

pleunv أعتقد أن هذا قد يكون مرتبطًا: https://github.com/facebook/jest/pull/9294. لقد لاحظت أن الارتباطات التشعبية تبطئ iTerm2 على جهازي ، مما يجعلها متقطعة. لكن لم يتم التحقيق في السرعة الإجمالية للتنفيذ ، ولم يتم العثور على شخص آخر لديه مشاكل معه.

يوريكا. البحث عن "iTerm" أوصلني إلى هذا العلاقات العامة . لقد لاحظت هذه التسطير من قبل ولم أدرك أنها كانت ارتباطات تشعبية. بعد رؤية العلاقات العامة ، قمت بتعطيل الارتباطات التشعبية في iTerm مما أدى إلى خفض وقت التشغيل إلى 130 ثانية. بعد تطبيق الكود من PR وإزالة الارتباطات التشعبية ، عدت إلى 120 ثانية. استعادة العقل قليلا.

أي فرصة لاستعادة العلاقات العامة؟

تحرير: ضربني thymikee إلى ذلك 😄

pleunv سأحاول إيجاد بعض الوقت هذا الأسبوع لإعادته. على الرغم من أن الصفقة الحقيقية تتمثل في إصلاح هذا الأمر بالنسبة إلى iTerm ، إلا أن المحطات الطرفية الأخرى على سبيل المثال في Linux لا تواجه مشكلات مع الارتباطات التشعبية. هل تمانع في رفع قضية إلى مشروع iTerm؟

لقد أجريت هذا التغيير للتو وأعطاني 1 ثانية لملف اختبار واحد. ولا يزال بإمكانك النقر فوق عنوان url ، فلم يعد تحته خط.

قد يكون هذا ضخمًا لعمليات التشغيل الأكبر. ❤️

//تعديل
الشيء المضحك أنه لم يحدث فرقًا من قبل إذا كان iterm أو المحطة الطرفية. بعد التغيير يكون iterm أسرع بالنسبة لي.

pleunv سأحاول إيجاد بعض الوقت هذا الأسبوع لإعادته. على الرغم من أن الصفقة الحقيقية تتمثل في إصلاح هذا الأمر بالنسبة إلى iTerm ، إلا أن المحطات الطرفية الأخرى على سبيل المثال في Linux لا تواجه مشكلات مع الارتباطات التشعبية. هل تمانع في رفع قضية إلى مشروع iTerm؟

لقد قمت بإنشاء مشكلة هنا (إنهم موجودون على GitLab). إذا كان لدى أي شخص تفاصيل إضافية أو مشروع repro ، فلا تتردد في الإضافة.

كنت أقوم بتجربة المزيد في نفس الوقت ووجدت أنه عند تشغيلها فقط على مجموعة فرعية أصغر من الاختبارات (بضع عشرات من ملفات الاختبار) ، لا تُحدث الارتباطات التشعبية هذا فرقًا كبيرًا بشكل عام. عند تشغيله على مجموعتنا الكاملة على الرغم من (700 ملف) ، يكون التأثير قابلاً للقياس إلى حد كبير.

لدي أيضًا انطباع بأن إخراج وحدة التحكم في jest على المدى الطويل يبدأ في الحصول على بريق / لامع حقًا. خطوط التقدم في الجزء السفلي على سبيل المثال مخفية أكثر من كونها مرئية.