سيكون رائعًا إذا كان بإمكانك إرفاق repro يمكن للمرء التحقق منه وتحليله.

نشهد أيضًا تراجعًا كبيرًا في أداء Jest 24.

  System:
    OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  Binaries:
    Node: 10.15.0 - ~/.nvm/versions/node/v10.15.0/bin/node
    Yarn: 1.13.0 - ~/.nvm/versions/node/v10.15.0/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.15.0/bin/npm
  npmPackages:
    jest: 24.1.0 => 24.1.0 

هذا مع 1400 اختبار على قاعدة رمز كبيرة. تشغيل محول منسوب مخصص.

--all
الساعة 23.6.0: 13 ثانية
إنها الساعة 1:17 مساءً

--all --no-cache
إنها 23.6.0: 60 ثانية
24.1: 150 ثانية

--all --runInBand
إنها 23.6.0: 36 ثانية
الساعة 24.1: 40 ثانية

--all --no-cache --runInBand
إنها 23.6.0: 60 ثانية
الساعة 24.1: 65 ثانية

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

إليك مصدر مفتوح أنشأته بدافع المزاح للاختبار. يجري اختبارات الوحدات التقليدية واختبارات التكامل مع مكالمات API الحية. لقد لاحظت بالتأكيد تباطؤًا كبيرًا عند محاولة الترقية إلى jest @ 24.

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

https://github.com/mkreiser/ESPN-Fantasy-Football-API

لأكون أكثر فائدة ، قمت بإجراء بعض الإحصائيات. لسوء الحظ ، يبدو أن واجهة برمجة تطبيقات ESPN معطلة لذا لم أتمكن من إجراء اختبارات التكامل (والتي قد تكون أكثر إثارة للاهتمام) أيضًا.

env (عبر npx envinfo --preset jest )

System:
    OS: macOS 10.14
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  Binaries:
    Node: 8.15.0 - ~/.nvm/versions/node/v8.15.0/bin/node
    npm: 6.7.0 - ~/.nvm/versions/node/v8.15.0/bin/npm

الفروع

سيد = [email protected] ، jest-24 = [email protected]

أداء اختبار الوحدة (451 اختبارًا في 16 جناحًا) ( npm run test:unit )

[email protected] :

مرت الخيارات | زمن
- | -
(لا توجد خيارات) | 3.5 ثانية
- maxWorkers = 2 | 3.4 ثانية
--لا مخبأ | 8.6 ثانية
--لا مخبأ - MaxWorkers = 2 | 6.8 ثانية
--runInBand | 3.8 ثانية
--runInBand - بدون ذاكرة تخزين مؤقت | 8.3 ثانية

[email protected] :

مرت الخيارات | زمن
- | -
(لا توجد خيارات) | 4.4 ثانية
- maxWorkers = 2 | 4.7 ثانية
--لا مخبأ | 13.4 ثانية
--لا مخبأ - MaxWorkers = 2 | 17.6 ثانية
--runInBand | 5.1 ثانية
--runInBand - بدون ذاكرة تخزين مؤقت | 9.3 ثانية

تم التحقق من اختبارات الريبو هذه https://github.com/LambdaSchool/React-Testing ، النتائج:
الإصدار 23:
"" node_modules / .bin / jest - overbose
PASS src / __ الاختبارات __ / App.spec.js

✓ يُعرض بدون تحطم (13 مللي ثانية)

PASS src / __ الاختبارات __ / Panel.spec.js

✓ يُعرض بدون تحطم (13 مللي ثانية)

PASS src / __ tests __ / Display.spec.js

✓ يُعرض بدون تحطم (14 مللي ثانية)

PASS src / __ الاختبارات __ / Button.spec.js

✓ يُعرض بدون تحطم (2 مللي ثانية)

مجموعات الاختبار: 4 ناجح ، 4 إجمالي
الاختبارات: 4 مرت ، 4 في المجموع
لقطات: 0 المجموع
الوقت: 4.158 ثانية
تم تشغيل جميع أجنحة الاختبار.

v24
```node_modules/.bin/jest --verbose
 PASS  src/__tests__/Display.spec.js
  <Display />
    ✓ renders without crashing (13ms)

 PASS  src/__tests__/Panel.spec.js
  <Panel />
    ✓ renders without crashing (17ms)

 PASS  src/__tests__/App.spec.js
  <App />
    ✓ renders without crashing (23ms)

 PASS  src/__tests__/Button.spec.js
  <Button />
    ✓ renders without crashing (4ms)

Test Suites: 4 passed, 4 total
Tests:       4 passed, 4 total
Snapshots:   0 total
Time:        5.182s
Ran all test suites.

لا ينتج وضع Verbose توقيتات متسقة ، ولكن في الإصدار 24 غير المطول يكون في المتوسط ​​ثانية واحدة أبطأ من v23 (3.9 ثانية مقابل 4.9 ثانية على جهازي).
هذا هو الأرشيف الذي يحتوي على إعدادين https://www.dropbox.com/s/mgbviexw96l2o1z/JestReact-Testing٪2023vs24.zip؟dl=0

thymikee هل يمكننا إزالة علامة Windows هنا؟ هذا بالتأكيد موجود على MacOS و Ubuntu أيضًا.

يوجد الإصدار 24:

Test Suites: 96 passed, 96 total
Tests:       276 passed, 276 total
Snapshots:   129 passed, 129 total
Time:        113.429s

إنه الإصدار 23:

Test Suites: 96 passed, 96 total
Tests:       276 passed, 276 total
Snapshots:   129 passed, 129 total
Time:        17.288s

Woah، 17s vs 113s ، هذا ضخم! هل من إمكانية مشاركة هذا المشروع؟

أعتقد أننا بحاجة إلى البدء حقًا في التفكير في إضافة مراقبة الأداء إلى Jest. تحدث aaronabramov عن هذا في # 4471. تأتي Node بشكل أساسي مع نفس واجهة برمجة تطبيقات الأداء التي يوفرها المتصفح (متوفرة منذ العقدة 8): https://nodejs.org/api/perf_hooks.html ، فربما يمكننا استخدام ذلك لقياس؟ يجب أن يكون وجود طريقة ما لإصدار المدة التي تستغرقها الأشياء المختلفة هو الخطوة الأولى على الأرجح (لذا # 4471 ، لكن هذا يتحدث فقط عما يحدث داخل الاختبارات)

بالتأكيد ، هذا الريبو .

حاليًا لا أرغب في الترقية إلى الإصدار 24 بسبب هذا الاختلاف 😞

شكر!

على جهازي ، يستغرق ذلك 35-40 ثانية على ذاكرة التخزين المؤقت الباردة ، و 7-8 ثوانٍ على ذاكرة التخزين المؤقت الدافئة. مع jest 24 ، أحصل على 40-45 ثانية في ذاكرة التخزين المؤقت الباردة و 17-18 ثانية في ذاكرة التخزين المؤقت الدافئة. يُظهر المشكلة بالتأكيد (على الرغم من أنها ليست شديدة كما هو الحال في جهازك). سأحاول أن أجد بعض الوقت للحفر في هذا

لا أرغب حاليًا في الترقية إلى الإصدار 24 بسبب هذا الاختلاف

مفهوم!

ربما قمت بتشغيل v23 مع ذاكرة التخزين المؤقت و v24 بدون.

ولكن لدينا أيضًا إعادة شراء أخرى حيث أصبحت الاختبارات أبطأ بشكل ملحوظ بعد الترقية. ليس لدي أي توقيتات رسمية رغم ذلك.

أظن أن Babel 7 يساهم بشكل كبير في المشكلة ، تحقق من الالتزام 1818d84 والسابق ، أحصل على زيادة 0.5 ثانية لـ 4 اختبارات بسيطة.

تم الاختبار باستخدام npx jest; npx jest والوقت المستغرق لاحقًا (للحصول على ذاكرة التخزين المؤقت الساخنة).

الإصدار | الاختبارات | زمن
- | --- | ---
23.6.0 | 5749 | 59.13 ثانية
24.1.0 | 5749 | 144.5 ثانية
24.8.0 | 5812 | 125.88 ثانية

كما أن الفرق في النسبة المئوية بين ذاكرة التخزين المؤقت الساخنة والباردة أكبر بكثير

الإصدار | حار | بارد | فرق
--- | --- | --- | ---
23.6.0 | 58 ثانية | 65 ثانية | + 12٪
24.1.0 | 140 ثانية | 190 ثانية | + 35٪
24.8.0 | 126 ثانية | 145 ثانية | +16٪

والأسوأ من ذلك هو الفرق بين jest و jest --no-cache

الإصدار | jest (مخبأ ساخن) | jest - لا مخبأ | فرق
--- | --- | --- | ---
23.6.0 | 59 ثانية | 113 ثانية | + 92٪
24.1.0 | 144 ثانية | > 400 ثانية | +> 200٪
24.8.0 | 126 ثانية | 1318 ثانية | +> 1000٪

لقد أحبطت تشغيل - no-cache على 24.1 بعد 400 ثانية. مع 2669/5749 اختبار 113/621 جناح تم إنجازه. لذلك من المحتمل أن يكون إجمالي وقت التنفيذ في نطاق 800-900 ثانية.

تحرير: كان Jest 24.8.0 تحسنًا كبيرًا. وقت تشغيل أسرع قليلاً بالرغم من إجراء المزيد من الاختبارات.

هل هناك شخص يعمل على هذا لأن هناك تأنيبًا واضحًا؟
نشهد أيضًا تراجعاً هائلاً في الأداء عند التحديث إلى Jest 24. نظرًا لـ https://github.com/facebook/jest/issues/7709 ، يتعين علينا الترقية إلى Jest 24. في الوقت الحالي ، نستخدم حلًا إلى 2.4.1. لكتابة ملف ذري وهو بالتأكيد ليس مثاليًا ...

هناك # 8032 الذي حدد سبب واحد للانحدار

لقد قمنا مؤخرًا بالتبديل من Babel 6 / Jest 23 إلى Babel 7 / Node 24 ولاحظنا أيضًا انحدارًا صارخًا في السرعة (من 150 ثانية إلى 200 ثانية تقريبًا مع ذاكرة تخزين مؤقت نظيفة و ~ 100 ثانية إلى 160 ثانية مخبأة). لا يبدو أنه مرتبط بـ Babel 7 ، لأن تشغيل تجميع Babel في حد ذاته أسرع الآن.

مرحبًا ، أود مشاركة تجربتي هنا مع Jest.
أنا أحب المزاح ولكن المشكلة التي أواجهها تستغرق الكثير من الوقت لإجراء 6 اختبارات ، فقد استغرقت 13.4 ثانية

 PASS  test/domain/model/Actor.test.ts (12.193s)
  Actor creation
    √ should create an actor (5ms)
    √ should create an actor will publish ActorCreated event (3ms)
  Actor roles
    √ should create a role and to be an instance of it (15ms)
    √ should publish CreatorRoleAssignedToActor event when add a creator role to an actor (2ms)
    √ should publish UserRoleAssignedToActor event when add a user role to an actor (5ms)
    √ should create a user actor and publish UserRoleAssignedToActor domain event (1666ms)

Test Suites: 1 passed, 1 total
Tests:       6 passed, 6 total
Snapshots:   0 total
Time:        13.4s
Ran all test suites.

Watch Usage: Press w to show more.

npx envinfo --preset jest
npx: installed 1 in 2.847s

  System:
    OS: Windows 10
    CPU: (8) x64 Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz
  Binaries:
    Node: 11.7.0 - C:\Program Files\nodejs\node.EXE
    npm: 6.5.0 - C:\Program Files\nodejs\npm.CMD

أيضا في package.json

"scripts": {
  "test": "jest",
  "test:watch": "jest --watch",
},
"devDependencies": {
   "@types/jest": "^24.0.12",
   "jest": "^24.5.0",
   "jest-coverage-badges": "^1.1.2",
   "jest-junit": "^6.4.0",
   "ts-jest": "^24.0.2",
...etc
}

jest.config.js

module.exports = {
    preset: "ts-jest",
    testEnvironment: "node",
    coverageDirectory: "doc/code-coverage",
    collectCoverageFrom: [
        "src/**/*.{js,ts}",
        "!**/node_modules/**",
        "!**/vendor/**",
        "!src/index.ts"
    ],
    coverageReporters: ["json", "html", "json-summary", "jest-junit", "lcov"]
};

أنا أستخدمه مع الكتابة المطبوعة:

في مجلدي sh test ، لدي ملف به 6 اختبارات:

ثم حاولت استخدام الموكا

npm i -D chai @types/chai mocha @types/mocha sinon @types/sinon sinon-chai @types/sinon-chai source-map-support nyc

وأضع mocha.opts داخل مجلد "الاختبار"

--require ts-node/register
--watch-extensions ts
test/**/*.ts

وفي الحزمة. json:

    "scripts": {
        "test:watch": "mocha --opts test/mocha.opts --watch"
    },
...etc

أجريت نفس الاختبارات (فقط قمت بتعديل التأكيدات لاستخدام sinon-chai) ، وركضت بسرعة مذهلة (حوالي 1-2 ثانية) ،

Actor creation
    √ should create an actor
    √ should create an actor will publish ActorCreated event

  Actor roles
    √ should create a role and to be an instance of it
    √ should publish CreatorRoleAssignedToActor event when add a creator role to an actor
    √ should publish UserRoleAssignedToActor event when add a user role to an actor
    √ should create a user actor and publish UserRoleAssignedToActor domain event (325ms)


  6 passing (336ms)

شيء ما ليس جيدًا ولا أعرف ما هي المشكلة.

أي شيء يمكننا القيام به بخصوص هذا؟ أي نصيحة نهج؟
إنه بطيء بشكل مقلق.

انتهى بنا المطاف بالهجرة إلى Mocha (+ Chai و Sinon) ، والتي أبلغت عن تحسن كبير في وقت الاختبار.

أفكر في العودة إلى jest 23 حتى يتم إصلاحه ، إنه أبطأ بحوالي 3-5 مرات من ذي قبل بالنسبة لي.

أسرع إصدار دعائي كان 22.4.4 . جميع الإصدارات الأحدث كانت أبطأ بكثير.

deleteme كيف يتم v23 مقارنة بـ v22 ؟ هل فرق السرعة مهم؟ أريد أن أقترح الرجوع إلى 22 لكن زميلي قال إن الإصدار منخفض جدًا (مقارنة بـ 24 )

مرحبا! لا أريد أن أضيف إلى ضجيج هذا العدد ، لذلك سأبقيه بسيطًا وأضيف نسخة أخرى مفتوحة المصدر:

مشروع بحجم رمز كبير (على وجه الخصوص ، lexer واحد بحجم 2 ميغا بايت) ، حيث أدى تغيير واحد لترقية Jest 23.0.x إلى Jest v24.0.x إلى قفزة في أوقات الاختبار من ~ 7 ثوانٍ (~ 5 ثوانٍ لكل ملف اختبار) ، إلى ~ 147 (~ 70 ثانية لكل ملف اختبار فردي). نعم ، تراجع بنسبة 2000٪ . 🤯

المشروع ELLIOTTCABLE / excmd.js ؛ الالتزام ELLIOTTCABLE / excmd. js @ f0982114 استخدم jest --clearCache && time jest ؛ الالتزام التالي ، ELLIOTTCABLE / excmd. js @ d4d3a08d ، يقوم بتحديث Jest إلى الإصدار 24 ، ويظهر توقيت مسح ذاكرة التخزين المؤقت المتسق لـ ≥100 ثانية.

مرة أخرى ، حتى لا ينزلق - أظن بشدة أن تراجع الأداء له علاقة بنسخ نظام الملفات أو تحميل الوحدة ؛ لأن الشيء الذي يجعل مشروعي غريبًا هو بالتأكيد تحميل ملف واحد مشعر بحجم 2 ميغا بايت .js . (خطأ غير ذي صلة).

كما أنني لست مقتنعًا بأن الأمر يتعلق ببابل ؛ يقوم Babel بسعادة بتغيير تصميم هذا الملف ويستمر في طريقه المرح ، ويظهر وقت إنشاء ساعة الحائط 4.48s .

(لأنني متأكد من أن هذه المشكلة مرهقة (الكثير من الشكاوى من المستخدمين ، ويصعب إعادة إنتاجها ، وتتعلق بالأداء وبالتالي يصعب تصحيحها ...) ، أود أن أضيف: نحن نحب Jest ، وعمل الصيانة الشاق الذي تقوم به ، حتى الفرز حيث تقول "لا" ، هو موضع تقدير كبير. ❤️)

ronayumik من أي وقت مضى منذ Jest 22.4.4 ، حيث تم إصدار إصدارات جديدة من Jest ، وعندما أهتم بالترقية ، أقارن المدة التي يستغرقها تشغيل اختباراتنا (412 مجموعة اختبار ، اختبارات 2015).

يتضمن المفهوم التالي العديد من المعايير باستخدام Jest 22 و 23 و 24.

https://gist.github.com/deleteme/25fcca7cd16aceb30cc5f50e022aa706

حتى الآن ، كان كل إصدار جديد أبطأ بشكل ملحوظ.

deleteme هل حاولت مع micromatch معلقة على V4؟

thymikee No. هل تريد مني

لا ، يمكنك فقط استخدام قرارات الغزل

thymikee لقد قمت بتحديث جوهر المعيار الخاص بي لتشمل مقارنة jest @ 24.8.0 مع وبدون دقة غزل Micromatch 4.0.2 .

https://gist.github.com/deleteme/25fcca7cd16aceb30cc5f50e022aa706#benchmark -jest-2244-2480-with-Micromatch-yarn-Resolution-2480-without-Micromatch-yarn-Resolution

لا يزال هذا سيئًا جدًا: / ما زلت أشعر أن شيئًا ما يجب أن يكون خطأً في وقت تشغيل الدعابة ، لكن أتساءل ماذا

هذه ليست قضية مزحة. يتعلق الأمر بابل 7.
لقد قمنا بتحديث babel 6 إلى 7 في مشروعنا وحصلنا على حوالي 30٪ من تدهور أداء التجميع لنفس قاعدة الكود

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

smelukov لدينا أوقات تجميع Babel أسرع بـ 7 ، لكن Jest أبطأ.

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

jeysal أفعل بعض الأشياء للعثور على "عنق الزجاجة"
سأبلغ عند الانتهاء ؛)

agrasley نحن نستخدم بنية مخبأة

انتقلنا من Babel (الآن TS بالكامل مع ts-jest) وشاهدنا هذا الانحدار أيضًا من 23 إلى 24 (+ 40٪ زيادة الوقت للاختبارات المخزنة مؤقتًا ، + 100٪ للاختبارات غير المخزنة مؤقتًا). تزداد الذاكرة أيضًا. لم يكن لتثبيت micromatch على الإصدار v4 فائدة تذكر. لم يساعد استخدام أحدث jsdom (15) أيضًا.

لا يمكننا تجاوز إنشاء CI الخاص بنا بسبب مشكلات tko في الكومة في أحدث إصدار من jest (24).

أي شخص لديه أي حلول قصيرة المدى؟ أنا على استعداد لمساعدة العلاقات العامة في شيء ما إذا كان شخص ما يمكن أن يرشدني من أين أبدأ :)

بالنظر إلى الكود الخاص بعلامة --coverage ، يبدو أن هذا هو السبب الجذري لمشكلات الكومة.

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

هذه ليست قضية مزحة. يتعلق الأمر بابل 7.

إنها قضية الدعابة على الإطلاق. استخدمنا Babel 7 تحت Jest 23 و 24 وشاهدنا انخفاضًا حادًا في 24 بغض النظر.

لقد قمت بالتحديث من 24.7.1 إلى 24.8.0 وهو يعمل بسرعة مرة أخرى ، حتى أفضل من 23.6.0 كان.
بالنسبة إلى 400 اختبار تقريبًا ، كانت تستغرق من 50 إلى 90 ثانية ، والآن تستغرق 28-32 ثانية.
هل يمكن لأي شخص آخر المحاولة والتأكيد؟

لقد قمت بالتحديث من 24.7.1 إلى 24.8.0 وهو يعمل بسرعة مرة أخرى ، حتى أفضل من 23.6.0 كان.
بالنسبة إلى 400 اختبار تقريبًا ، كانت تستغرق من 50 إلى 90 ثانية ، والآن تستغرق 28-32 ثانية.
هل يمكن لأي شخص آخر المحاولة والتأكيد؟

لا يساعد. 1630 اختبارًا - 1152.588 ثانية. مشروع خاص.
--clearCache وفحص النوع ممكّنان ("عزل الوحدات": خطأ)
دقة الغزل micromatch 4.0.2 لم تساعدنا أيضًا.

سنقوم بتجربة أحدث إصدار (24.8.0) قريبًا وتقديم تقرير.

تحرير: بطيء في 24.8.0. أي شخص لديه حل؟ لدينا 5500 اختبار تقريبًا ولا يمكننا تشغيلها حرفيًا على أحدث إصدار (تموت في CI بسبب انتهاء المهلة أو تستغرق كل الأبدية (20+ دقيقة) مقابل 3 دقائق كانت تستغرقها).

سوف ألقي نظرة على الكود المصدري وأقوم ببعض الاختلافات لمعرفة ما يمكنني العثور عليه. قد أتمكن على الأقل من البدء ببعض المساعدة.

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

آمل أن ألاحظ بعض الأماكن التي تبطئ الدعابة 24 مقارنة بـ jest 22 ، إليك الرابط إذا كان شخص ما على استعداد لتجربته https://github.com/vitalibozhko/jest/tree/24.8.0-perf-spots (زوجان من التعديلات وبعض الميزات الثانوية المعطلة فقط لاختبار الأداء ، وليس إصلاحًا حقيقيًا)
أحصل على نفس الوقت تقريبًا في هذا الفرع كما كان في jest 22 في إعداد مشروعنا الخاص.

لتجربة ذلك ، ما عليك سوى اتباع https://github.com/facebook/jest/blob/master/CONTRIBUTING.md#how -to-try-a-development-build-of-jest-in-another-project
أود أيضًا أن أقترح إما تشغيل jest عن طريق البرامج النصية package.json أو عبر ./node_modules/.bin/jest للتأكد من استخدام الإصدار المرتبط (أنا شخصياً أستخدم الأخير).
تتمثل إحدى طرق التحقق من تعيين الارتباط بشكل صحيح في تشغيل المحطة الطرفية ./node_modules/.bin/jest --version - يجب أن تعطي 24.8.0-dev

هذا عظيم vitalibozhko! بالنظر إلى الفرق ، أرى 3 تغييرات رئيسية

1. الترقية إلى micromatch @ 4
2. نقل مجموعة المكدس (ربما حتى إزالتها؟ لقد قمت بالقشط من خلالها)
3. لا تستخدم تنسيقًا رائعًا لتنسيق تم طرحه بدون أخطاء

هل هذا يبدو صحيحا؟ إذا كانت الإجابة بنعم ، فما الأجزاء التي كان لها التأثير الأكبر؟ بعض التعليقات على التغييرات:

1. سنقوم بترقية micromatch في jest 25.
2. كنت أخشى أن يكون للحرص على جمع الأكوام تأثير سلبي على الأداء: https://github.com/facebook/jest/pull/6965#issuecomment -421612367. لست متأكدًا مما يجب فعله هنا - فالمكدسات مهمة لفهم الخطأ الذي حدث إذا فشلت الاختبارات. ربما يمكننا إضافة خيار لها ، حتى يتمكن الأشخاص من الاشتراك في آثار أفضل؟ يتم تنشيطها عندما تفشل الاختبارات (من المحتمل) في الحصول على تتبع أفضل
3. أنا مندهش قليلاً من تغيير التنسيق الجميل - لا أتوقع أن يكون ذلك ثقيلًا حيث يتم طرح Error s في معظم الأوقات ولم يتم تنشيط مسار الرمز هذا.

يبدو الاشتراك فكرة جيدة - وبهذه الطريقة يمكنني الركض بسرعة على ci والمزيد من الإسهاب محليًا عندما أرغب حقًا في تصحيح شيء ما.

vitalibozhko بافتراض

260 مجموعة / 1583 اختبار / mbp رباعي النواة / أوقات التشغيل الثانية معروضة

22.4.4: 47 ثانية
23.6.0: 54 ثانية
24.8.0: 72 ثانية
24.8.0 نقاط أداء: 72 ثانية

تحرير: يبدو أن إصدار العقدة له تأثير كبير على هذا أيضًا ، فالانتقال إلى العقدة 10 من العقدة 8 يأخذ 10-15 ثانية من الأوقات المذكورة أعلاه.

(حاولت اختبار أحدث التزام رئيسي أيضًا ولكني كنت أتلقى أخطاء نحوية ، وما زلت أتلقى نفس الأخطاء عندما عدت لإعادة ربط فرع dynamicibozhko ، ولا أشعر بالرغبة في العبث به بعد الآن ..)

تضمين التغريدة

أرى 3 تغييرات رئيسية

الترقية إلى micromatch @ 4
نقل مجموعة المكدس (ربما حتى إزالتها؟ لقد قمت بالقشط من خلالها)
لا تستخدم تنسيقًا رائعًا لتنسيق تم طرحه بدون أخطاء
هل هذا يبدو صحيحا؟

يبدو ذلك صحيحًا

ما الأجزاء التي كان لها التأثير الأكبر؟

أود أن أقول إن التأثير الأكثر وضوحًا يأتي من طلب وحدات "ثقيلة" مثل التنسيق الجميل على الرغم من أن تلك مطلوبة فقط في ظل ظروف معينة (على سبيل المثال ، تستخدم المواصفات لقطات ، وفاشلة الحاجة إلى تنسيق الخطأ ، وما إلى ذلك). كانت التغييرات التي تم إجراؤها هي الأماكن الأكثر وضوحًا من مخطط اللهب الشخصي.
فيما يتعلق بحمل وحدة المعالجة المركزية ، هناك شيء واحد واضح - getAllCoverageInfo باستخدام deepCyclicCopyObject (7٪ من إجمالي الوقت) ، تم استبداله بـ JSON.parse (JSON.stringify ()) ، فهو مناسب تمامًا لـ استنساخ التغطية - في حالة مشروعي ، يتم تقليل وقت الاستنساخ الإجمالي من 2.3 ثانية إلى 0.4 ثانية

كنت أخشى أن يكون للحرص على جمع الأكوام تأثير سلبي على الأداء: # 6965 (تعليق). لست متأكدًا مما يجب فعله هنا - فالمكدسات مهمة لفهم الخطأ الذي حدث إذا فشلت الاختبارات. ربما يمكننا إضافة خيار لها ، حتى يتمكن الأشخاص من الاشتراك في آثار أفضل؟ يتم تنشيطها عندما تفشل الاختبارات (من المحتمل) في الحصول على تتبع أفضل

ضع مجموعة المكدس مرة أخرى - حصلت على plus 1-2 (15.5> 16.5-17.x) إلى إجمالي الوقت في ذاكرة التخزين المؤقت الساخنة مع تنفيذ النطاق.
مجموعات الاختبار: 66 ناجحًا ، إجمالي 66
الاختبارات: تم تخطي 16 ، اجتياز 441 ، المجموع 457
لقطات: 9 مرت ، 9 المجموع
الوقت: 17.398 ثانية

قد يكون من المفيد محاولة قياس الذاكرة المحتجزة بدون تقييم المكدس ، وأظن أنها ستصبح مشكلة في وضع المراقبة فقط.

أنا مندهش قليلاً من تغيير التنسيق الجميل - لا أتوقع أن يكون ذلك ثقيلًا حيث يتم إلقاء الأخطاء في معظم الأوقات وعدم تنشيط مسار الرمز هذا.

كما ذكرنا سابقًا ، ليس وقت التنفيذ هو ما يحدث فرقًا ، بل هو وقت طلب وحدة نمطية

راجع للشغل ، أنا أتحقق من الأداء على العقدة v11.10.0

اسمحوا لي أن أشارك التنميط الخاص بي هنا.
المواصفات:

• نظام التشغيل Windows 10 Pro
• العقدة 10.15.3
• Intel Core i7-4702MQ 2.2 جيجا هرتز
• 8 جيجا رام
• إلى x64
• SSD

خطوات:

1. npx create-react-app my-app --typescript
2. تغيير App.test.tsx
3. تشغيل npm test

ملف تعريف وحدة المعالجة المركزية:

CPU-20190801T141211.zip

هل من المتوقع أن يتم قضاء 15 ثانية فقط في إعادة الوحدات النمطية لمكون React الفردي البسيط والاختبار؟

هل يمكن لشخص يتمتع بخبرة أكبر في توصيف وحدة المعالجة المركزية إلقاء نظرة؟

أجريت اختبارًا على 24.9 مقابل 24.8 على أحد أجنحتنا. لا توجد تحسينات للأسف.

24.8 ، مخبأ بارد:

Test Suites: 3 skipped, 112 passed, 112 of 115 total
Tests:       5 skipped, 494 passed, 499 total
Snapshots:   5 passed, 5 total
Time:        29.323s
Ran all test suites.
✨  Done in 30.65s.

24.8 ، مخبأ دافئ:

Test Suites: 3 skipped, 112 passed, 112 of 115 total
Tests:       5 skipped, 494 passed, 499 total
Snapshots:   5 passed, 5 total
Time:        19.109s, estimated 26s
Ran all test suites.
✨  Done in 19.91s.

24.9 ، مخبأ بارد:

Test Suites: 3 skipped, 112 passed, 112 of 115 total
Tests:       5 skipped, 494 passed, 499 total
Snapshots:   5 passed, 5 total
Time:        29.684s
Ran all test suites.
✨  Done in 30.57s.

24.9 ، مخبأ دافئ:

Test Suites: 3 skipped, 112 passed, 112 of 115 total
Tests:       5 skipped, 494 passed, 499 total
Snapshots:   5 passed, 5 total
Time:        20.909s, estimated 27s
Ran all test suites.
✨  Done in 21.65s.

نستخدم المزاح لاختبار تطبيق Angular 8 الخاص بنا باستخدام babel-jest و ts-jest. اعتدنا على إجراء 200 اختبار في أقل من 5 دقائق على hest 23 والآن مع 24.9 ، فقد تجاوزنا 20 دقيقة وهو أمر غير مقبول تمامًا. أنا أستخدم العقدة 10. الوقت أكبر لكل من البداية الباردة وأيضًا مع ذاكرة التخزين المؤقت.

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

هذا انحدار مروع 🙁 هل مشروعك مفتوح المصدر؟

هل جربت الفرع من https://github.com/facebook/jest/issues/7811#issuecomment -516718977؟

الشيء الآخر الذي سيساعد على الأرجح هو تحديث الكود الخاص بنا لاستهداف العقدة 8 - والتي ستتوقف عن تحويل async-await . يمكنك القيام بذلك عن طريق تغيير هذا الخط: https://github.com/facebook/jest/blob/e76c7daa33a7665396679527bba7d0fdfeb2591d/babel.config.js#L30

SimenB لا مشروعي ليس مفتوح المصدر.

لا أريد بناء Jest بمفردي. لأن هذا ما تقترحه ، أليس كذلك؟

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

هل هناك فرصة لإصلاح يمكن دمجها وإصدار نسخة جديدة؟
شكر!

دعم بالكامل tscislo حول مشكلة الأداء مقارنة jest23 و jest24.
SimenB ، آسف
إذا فاتتك رسالتي السابقة - دقة غزل Micromatch 4.0.2 لا تساعد.

tscislo هل يمكنك التوضيح ، ما هو "الاسم" الذي تتحدث عنه؟ أعتقد أن التسريع المخزن مؤقتًا قد يساعدني وشخص آخر.

DavyJohnes مبكرًا بعد إصدار 24 ، كان هناك خطأ في ذاكرة التخزين المؤقت تطلب من المستخدمين تعيين name يدويًا في التكوين الخاص بهم للتأكد من عمل ذاكرة التخزين المؤقت على النحو المنشود. إلى معرفتي التي تم تصحيحها لبعض الوقت الآن ، راجع https://github.com/facebook/jest/pull/7746

تضمين التغريدة

بعد هذا السؤال عن المصدر المفتوح / لا والصمت.

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

أما بالنسبة لـ "الصمت" ، فمن المؤكد أن الفريق لم يتم تعيينه للعمل في Jest وأنهم مشغولون بوظائفهم اليومية مثلك أنت وأنا. إنه مشروع مفتوح المصدر ، لا شيء يمنعك من محاولة اكتشاف المشكلة بنفسك.

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

هل غالبية (أي؟) من قواعد الكود لا تواجه هذه المشكلة؟ معظم الناس لا يهتمون؟

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

يتم تمكين ذاكرة التخزين المؤقت tscislo افتراضيًا ويجب أن تعمل إلا إذا

https://jestjs.io/docs/en/cli#cache

csvan شكرًا ، ولكن هذا ليس كيف يعمل بالنسبة لي

tscislo كيف تبدو تهيئة jest الخاصة بك؟

حول الموضوع: من بين الأشياء المذكورة في هذه المشكلة التي تساعد ، وصلنا إلى 2: لقد أسقطنا Node 6 وقمنا بترقية Micromatch في الفرع next . قللت هذه الأشياء من وقت التشغيل التجريبي بحوالي 10٪ لاختبارات Jest الخاصة (المزيد على Windows). كما أنه يقلل من استخدام الذاكرة بمقدار ضئيل. سنحاول إصدار إصدار ألفا قريبًا حتى يتمكن الأشخاص من اختباره ، ولكن يمكنك أيضًا التحقق من هذا الفرع محليًا ، وبناء وربط الدعابة في مشروعك لمعرفة كيف ستسير الأمور. التعليمات موجودة في CONTRIBUTING.md في جذر هذا الريبو. يجب أن يكون من الأسهل أيضًا إنشاء ملف تعريف Jest الآن لأننا لم نعد نحول async-await مما يجعل متابعة مكالمات الوظائف أسهل بكثير

أود أن أنظر في سبب صعوبة طلب pretty-format (والوحدات النمطية الأخرى داخل الصندوق الرمل) - شجرة التبعية الخاصة بها ليست كبيرة بهذا الحجم. لا توجد وعود على الرغم من _when_ رغم ذلك!

خارج الموضوع:

لا أريد بناء Jest بمفردي. لأن هذا ما تقترحه ، أليس كذلك؟

نعم ، هذا ما كنت أقترحه. لماذا لا تريد مساعدتنا في معرفة ما إذا كانت هذه التغييرات تساعد؟

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

كما يشير csvan ، تم إصلاح الشيء name منذ 24.1.0 (تم ربط PR). إذا كان هناك فرق في إضافة name أو لا للإصدارات بعد ذلك ، فيرجى فتح مشكلة جديدة لأن هذا تحسين لا يجب عليك إجراؤه.

ما هو الشرط عندما يستخدم Jest ذاكرة التخزين المؤقت؟

يستخدم Jest دائمًا ذاكرة التخزين المؤقت. يؤدي تمرير --no-cache فقط إلى حذف ذاكرة التخزين المؤقت السابقة - سيظل Jest يخزن الأشياء مؤقتًا داخل هذا التشغيل. نقوم بتخزين نتائج التحولات والاختبار مؤقتًا (حتى نعرف المدة التي استغرقتها ، ويمكننا تحديد أولويات وقت إجراء الاختبارات).

مثل csvan يقول - لا يتقاضى أي شخص أجرًا فعليًا للعمل في Jest ، لذا فإن أي وقت يقضيه هو إما وقت

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

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

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

أود أن أنظر في سبب صعوبة طلب التنسيق الجميل

قد يكون ذلك ، لأنه يتكون من الكثير من الملفات الفردية الصغيرة. قد يساعد تجميع التنسيق الجميل في التخفيف من ذلك.

هذا هو الرسم البياني للملف للحزمة:

• index.js
  
  
  
  • ./collections.js
  
  
  • أنماط ansi
  
  
  • ./plugins/AsymmetricMatcher.js
  
  
  • ./collections.js
  
  
  • ./plugins/ConvertAnsi.js
  
  
  • ansi-regex
  
  
  • أنماط ansi
  
  
  • ./plugins/DOMCollection.js
  
  
  • ./collections.js
  
  
  • ./plugins/DOMElement.js
  
  
  • ./lib/markup.js
    
    
    
    
    
    • ./escapeHTML
    
    
    
  
  
  • ./plugins/Immutable.js
  
  
  • ./collections.js
  
  
  • ./plugins/ReactElement.js
  
  
  • ./lib/markup.js
    
    
    
    
    
    • ./escapeHTML
    
    
    
  
  
  • رد فعل هو
  
  
  • ./plugins/ReactTestComponent.js
  
  
  • ./lib/markup.js
    
    
    
    
    
    • ./escapeHTML.js
    
    
    
  
  

وفقًا لنتائج google القديمة التي يمكن أن أجدها في هذا الشأن ، فإن node.js لا يحب ذلك حقًا. ومع ذلك ، لست متأكدًا مما إذا كان هذا صحيحًا بالنسبة لإصدارات node.js الحديثة. لكن إجراء مكالمات 3 مقابل 22 require() سيساعد قليلاً على أي حال.

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

إحضار هذا مرة أخرى: أظن أن Node العادي require لديه الكثير من التحسينات التي نفقدها لأن require يأتي حقًا من jest-runtime . ربما يمكن التحقق من ذلك من خلال النظر في المدة التي تستغرقها أشجار الوحدات للتحميل في وقت تشغيل Node vs Jest العادي

نعم ، هذه نقطة رائعة. يجب أن نحاول بالتأكيد معرفة ما إذا كانت خوارزمية require تفتقد إلى أي تحسينات يمكننا تطبيقها. إذا كان ينشئ الكائن module نفسه ، أو المحلل ، أو أي شيء آخر.

يتم إنشاء الوظيفة require هنا ، إذا أراد أي شخص البحث: https://github.com/facebook/jest/blob/d523fa84f2a65adf4d18019173dd44600c57bcad/packages/jest-runtime/src/index.ts#L884 -L922

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

أنا أشعر بك. لكي نكون صادقين ، يتمتع أي من مستخدمي Windows بحرية استخدام WSL ، ومن المرجح أن تختفي مشكلات الأداء الكبيرة.

ظننت أنني سأبدأ بتقرير عن مغامرات الأداء المزاح الشهر الماضي.

837 مجموعة ، 16259 اختبارًا ، واجهة Node v10 TypeScript خلفية ، تطبيق عالمي مع Vue + Nuxt

... وبالطبع ، الريبو الخاص :)

في البداية ، استغرقت هذه الاختبارات ... 4m30s w / cold cache or 3m20s w / hot cache على كل من Windows و WSL. كانت كلتا الحالتين أسرع بنحو 30 ثانية على MacOS أو Ubuntu

أعلم أن هذا مجرد سرد ، ولكن هذه أشياء حاولت ...

• لم يكن لإدراج أدلة العمل في القائمة البيضاء في برامج أمان Windows أي تأثير.
• لم يكن للتبديل من WSL إلى Windows "الخام" أي تأثير.
• أدى استخدام runInBand تدهور الأداء بشدة (تحتوي محطة العمل هذه على Xeon مع 20 مركزًا افتراضيًا)
• لقد قلصته إلى maxWorkers=4 باعتباره الخيار الأقل سوءًا.
• لم يكن تغيير بيئة المزاح بعيدًا عن jsdom خيارًا في البداية ، نظرًا لأن الكود قيد الاختبار هو تطبيق عالمي ، ولكن انظر أدناه.

في النهاية ، هذه هي الأشياء التي ساعدت فريقي:

• أدى التبديل إلى Ubuntu (Windows غير المثبت) إلى تقليل أوقات الاختبار بنسبة 15٪ تقريبًا
• التراجع إلى jest v22 ثم قلل أوقات الاختبار لدينا بنسبة أخرى ~ 40٪ أو نحو ذلك
• منحنا تقسيم مجموعات الاختبار إلى جانب العميل والخادم (في تطبيقنا العالمي) وتشغيلها بشكل فردي بعض المرونة ، على النحو التالي ...
• عند العمل محليًا في منطقة معينة ، يمكننا تشغيل مجموعة واحدة فقط ، مما يقلل الوقت بنسبة 50٪ تقريبًا
• علاوة على ذلك ، تمكنت من تبديل مجموعة الاختبار "من جانب الخادم" من jest-environment-jsdom-global إلى jest-environment-node . هذا حلق آخر ~ 25٪ أو نحو ذلك. (لقد جربت أيضًا node env لكنها أعطتنا أشياء غريبة في حلقة الأحداث لم يكن لدي وقت لاستكشافها ، ولم تكن هناك فائدة أداء ملحوظة على jest-environment-node )
• أستخدم برنامجًا نصيًا صغيرًا من shell لتشغيل مجموعتي الاختبار بالتوازي لتشغيل كامل ، ولا يستغرق الأمر سوى 25٪ أكثر من تشغيل كل منهما على حدة ، وهو ما يمثل توفيرًا صافياً هامًا على مدار التشغيل بالكامل دفعة واحدة.

أمل أن هذا يساعد شخصاما. خلاصة القول: كان التراجع إلى jest v22 أكبر مكسب فردي. FWIW كان جميع زملائي يواجهون المشكلات ، ونقوم بتشغيل كل نظام تشغيل بمجموعة متنوعة من تكوينات الأجهزة.

lulubo شكرا! لماذا تقترح التراجع إلى الرقم 22 وليس 23؟

lulubo شكرا! لماذا تقترح التراجع إلى الرقم 22 وليس 23؟

عفوًا ، آسف نسيت أن أذكر هذا الجزء. كانت اختبارات الأداء التي أجريناها مع الإصدار 23 أفضل بشكل هامشي من الإصدار 24. أنا آسف لأنني لا أستطيع تذكر الأرقام أو النسبة المئوية بالضبط ، لكن الإصدار 22 كان المكان الذي رأينا فيه المكاسب الكبيرة.

لقد بحثت في الريبو المقدم من https://github.com/facebook/jest/issues/7811#issuecomment -501876636 ، وكان الالتزام الذي جعل التشغيل التجريبي من 9 إلى 150 ثانية على جهازي هو # 7170. ومع ذلك ، إذا قمت بإزالة collectCoverage من التكوين ، فسيتم إكمال 24.8.0 أيضًا في 9 ثوانٍ. لذا فإن التغيير في هذه الحالة هو أننا نجمع بالفعل تغطية من الملفات المحددة ، وهو أمر مكلف (_ خاصة_ للملفات الكبيرة). لدي فرع يتحول لاستخدام تغطية V8 (# 8596) والتي من شأنها أن تسرع البعض ، لكنها ستكون باهظة الثمن دائمًا.

اختبار سريع:

مع إصلاح الخطأ الذي أدى إلى إبطائه ، وإلا فإن كل التعليمات البرمجية في الدعابة متطابقة:

شكرا على المعلومات التفصيليةlulubo! أعتقد أنه بعد أن نعود 24 مرة إلى حيث كان 23 ، يمكننا النظر في العودة إلى حيث كان الرقم 22 أيضًا. حتى لو لم تحدث 24-> 23 فرقًا كبيرًا بالنسبة لك ولفريقك ، يبدو من هذه المشكلة أنها مشكلة لكثير من الأشخاص ، لذلك أعتقد أننا يجب أن نركز على ذلك أولاً.

نجاح باهر! نشكرك على تخصيص بعض الوقت للنظر في رمز شخص آخر! 😳

حسنًا ، يبدو أن الحل بالنسبة لي هو فصل التغطية إلى تغطية مختلفة ،
مهمة المسار الأقل خطورة. العودة إلى التجارب 9s هو! 😍

يوم الثلاثاء 20 أغسطس 2019 الساعة 14:39 Simen Bekkhus [email protected]
كتب:

لقد حفرت في الريبو المقدم منELLIOTTCABLE
https://github.com/ELLIOTTCABLE في # 7811 (تعليق)
https://github.com/facebook/jest/issues/7811#issuecomment-501876636 ،
وكان الالتزام الذي جعل التشغيل التجريبي ينتقل من 9 إلى 150 ثانية على جهازي

7170 https://github.com/facebook/jest/pull/7170 . ومع ذلك ، إذا قمت بإزالة

collectionCoverage من التكوين ، يكتمل 24.8.0 أيضًا في 9 ثوانٍ. وبالتالي
التغيير في هذه الحالة هو أننا نجمع بالفعل تغطية من الملفات
المحدد ، وهو مكلف ( خاصة للملفات الكبيرة). لدي
تحويل الفرع لاستخدام تغطية V8 (# 8596
https://github.com/facebook/jest/pull/8596 ) والتي يجب أن تسرعها
البعض ، لكنها ستكون باهظة الثمن دائمًا.

اختبار سريع:
[صورة: صورة]
https://user-images.githubusercontent.com/1404810/63378220-0a7b3900-c392-11e9-8ee4-f9642133bc1e.png

مع إصلاح الخلل الذي أبطأ ، وإلا فإن كل التعليمات البرمجية في الدعابة هي
مطابق:
[صورة: صورة]
https://user-images.githubusercontent.com/1404810/63378229-12d37400-c392-11e9-8034-558091524986.png

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/facebook/jest/issues/7811؟
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAABSEQECUMAV4ZPND6VR3QFRB7XANCNFSM4GURCVKA
.

>

⁓ ELLIOTTCABLE - آمن للطيران.
http://ell.io/tt

أعتقد أنه بعد أن نعود 24 مرة إلى حيث كان 23 ، يمكننا النظر في العودة إلى حيث كان الرقم 22 أيضًا.

SimenB هذه أخبار رائعة. لدي نقطة بيانات أخرى لإضافتها إلى معايير v22 و 23 و 24 الخاصة بي المنشورة هنا https://github.com/facebook/jest/issues/7811#issuecomment -502837365. مجموعة اختبار jest في المعايير لا تستخدم الخيار collectCoverage .

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

إذا لم يكن مفتوح المصدر ، فأنا أحب أن تتمكن من الاختبار باستخدام الفرع next في هذا الريبو (على الرغم من أنه لا ينبغي أن يكون مختلفًا جدًا عن 23.x). إذا كان لديك الوقت ، فسيكون رائعًا إذا أمكنك تقسيم إعادة البيع المزاح إلى مشروعك - وهذا ما فعلته في المنشور أعلاه.

SimenB لقد نشرت مشاكل أداء مماثلة مع 24.8 أقمار عديدة في هذا الموضوع. سأعيد الاختبار مع الريبو الخاص بشركتي بتعليماتك غدًا ونشر النتائج.

SimenB شكرا للنظر بعناية في هذا. هل تعتقد أن جمع التغطية غالبًا وراء الأداء الضعيف؟ هل أفهم بشكل صحيح؟ المشكلة هي أنني لا أجمع التغطية وما زلت أرى هذا الأداء ينخفض.

SimenB لقد نشرت مشاكل أداء مماثلة مع 24.8 أقمار عديدة في هذا الموضوع. سأعيد الاختبار مع الريبو الخاص بشركتي بتعليماتك غدًا ونشر النتائج.

نعم ، هذا الخيط كبير جدًا وغير عملي ... شكرًا للتحقق!

هل تعتقد أن جمع التغطية غالبًا وراء الأداء الضعيف؟ هل أفهم بشكل صحيح؟

لا ، فقط في تلك الحالة المحددة - لا أعتقد أن التغطية هي المشكلة في الحالة العامة. ومع ذلك ، فإن النسخ الأخرى التي نظرت إليها اليوم شهدت جميعها انحدارًا من 8 إلى 7 ثوانٍ وما إلى ذلك ، لذلك لم أنظر إليها عن كثب بعد. من الأسهل العثور على الجاني إذا كان الاختلاف كبيرًا.

SimenB تنتمي مجموعة الاختبار إلى

واجهت صعوبة في استخدام yarn link مقابل jest-cli بسبب مشكلة عدم توافق babel 6 vs 7. لذا ، بدلاً من ذلك ، حاولت إجراء git bisect لـ jest repo عن طريق عمل yarn add /path/to/jest/packages/jest ، بين علامات git v22.4.4 و v23.6.0.

أظن أنه نظرًا لأنني لم أكن أستخدم yarn link ، فإن أسلوب استخدام yarn add /path/to/jest/packages/jest لم يكن يختبر التغييرات الفعلية لكل التزام ، ولكن مهما كان الإصدار الذي تم إصداره في ذلك الالتزام.

على أي حال ، كانت نتيجة هذا النصف (معيبة كما كانت) أن 614f739378d4f1757d8dc99219309553db5b9403 كان جيدًا ، و 7922488d676aa7bc5a6334699df220c7b001e299 كان سيئًا.

614f739378d4f1757d8dc99219309553db5b9403 كان له نفس متوسط ​​مدة الاختبار (9.36 ثانية). 7922488d676aa7bc5a6334699df220c7b001e299 كان متوسط ​​وقت الاختبار أبطأ بكثير (15.47 ثانية).

سأحاول مرة أخرى الحصول على yarn link مقابل jest-cli .

لقد أصدرنا jest@next من الفرع (المدمج الآن) next الفرع ، إذا أراد أي شخص اختباره

deleteme ما فعلته هو حذف الدعابة من الريبو الذي كنت أتحقق منه ، وفعل فقط ../jest/jest - لا حاجة إلى ربط. قمت أيضًا بتشغيل yarn && yarn add -D -W @babel/core babel-core<strong i="11">@bridge</strong> --ignore-scripts لتجنب مشكلة عدم تطابق إصدار babel-core.

تم اختباره على مدار 24.8 مقابل

Jest 24.8 ، مخبأ بارد:

مجموعات الاختبار: تم تخطي 3 ، وتم اجتياز 112 ، وإجمالي 112 من أصل 115
الاختبارات: تم تخطي 5 ، اجتياز 494 ، المجموع 499
لقطات: 5 مرت ، 5 المجموع
الوقت: 26.764 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حرر في ٢٧.٨٨.

Jest 24.8 ، مخبأ دافئ:

مجموعات الاختبار: تم تخطي 3 ، وتم اجتياز 112 ، وإجمالي 112 من أصل 115
الاختبارات: تم تخطي 5 ، اجتياز 494 ، المجموع 499
لقطات: 5 مرت ، 5 المجموع
الوقت: 20.792 ثانية ، يقدر بـ 24 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حرر في 21.35 ثانية.

جيست 25.0 (@ التالي) ، مخبأ بارد:

مجموعات الاختبار: تم تخطي 3 ، وتم اجتياز 112 ، وإجمالي 112 من أصل 115
الاختبارات: تم تخطي 5 ، اجتياز 494 ، المجموع 499
لقطات: 5 مرت ، 5 المجموع
الوقت: 24.008 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حرر في 24.78 ثانية.

جيست 25.0 (@ التالي) مخبأ دافئ:

مجموعات الاختبار: تم تخطي 3 ، وتم اجتياز 112 ، وإجمالي 112 من أصل 115
الاختبارات: تم تخطي 5 ، اجتياز 494 ، المجموع 499
لقطات: 5 مرت ، 5 المجموع
الوقت: 20.267 ثانية ، يقدر بـ 22 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حرر في 20.86 ثانية.

هذا عظيم الشكر! يطابق نتائجنا

لقد أخرتني مشكلات بيئة Node- jest @ next ، لكنني أردت نشر بعض النتائج الأخرى.

مشروع Windows 10 ، Node v10.14.2 مع Typescript

مجموعات الاختبار: 1492 المجموع
الاختبارات: 9668 المجموع

قام بتجميع بعض تغييرات التكوين الأخرى بناءً على المناقشات في هذا الموضوع. بالدرجة الأولى:

• تم إيقاف جمع تغطية التعليمات البرمجية
• تمت إعادة ترتيب moduleFileExtensions بحيث يكون ts و tsx في مقدمة القائمة

Jest 24.8 baseline ، Cold Cache: 629 ثانية
Jest 24.8 baseline ، Warm Cache: 296 ثانية

Jest 24.8 مع تغييرات التكوين ، ذاكرة التخزين المؤقت الباردة: 445 ثانية
Jest 24.8 w / config التغييرات ، Warm Cache: 209 ثانية

مقارنة بـ jest 23.6 ، توصلت إلى الاستنتاجات التالية:

• وقت التخزين المؤقت الدافئ في 24.8 قريب جدًا من وقت التخزين المؤقت الدافئ في 23.6. لسوء الحظ ، لا يزال الأمر أكثر من 3 دقائق ، ولكن مع مشروع بحجمنا أعتقد أن هذا مساوٍ للدورة.
• لا يزال وقت التخزين المؤقت البارد أبطأ بنحو 60 ثانية من وقت التخزين المؤقت البارد في 23.6. ولكن استنادًا إلى النتائج التي توصل إليها الآخرون ، فأنا متأكد بمجرد تشغيل jest @ next ، يجب أن نرى هذا الوقت البارد لذاكرة التخزين المؤقت.

بمجرد أن أصلح مشكلات بيئتي ، سأقوم بالتحديث بهذه النتيجة أيضًا.

آسف بشأن مشكلة node-gyp - لقد قمت للتو بدمج PR الذي يجب أن يصلحه (# 8869). نأمل أن نتمكن من الحصول على إصدار جديد معها.

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

على سبيل المثال ، تقوم Jest نفسها بتجميع التغطية فقط على العقدة 10 على CI (لينكس) - محليًا لم يتم تنشيطها.

القياسات التالية مأخوذة من ذاكرة تخزين مؤقت دافئة. حجم العينة لكل 10 أشواط.

نسخة الدعابة | يعني s | الأمراض المنقولة جنسياً | دقيقة ثانية | ماكس s
- | - | - | - | -
25.0.0 | 17.057 | 0.301 | 16.464 | 17.661
24.9.0 | 19.36 | 0.426 | 18.442 | 19.87
23.6.0 | 11.922 | 0.287 | 11.461 | 12.404
22.4.4 | 9.063 | 0.523 | 7.966 | 9.546

شكر! لا يزال أسوأ بكثير من 23 ... أي مساعدة في التقسيم سيكون موضع تقدير كبير. هل لاحظت ما إذا كان الوقت المتزايد هو للاختبارات نفسها ، أو التمهيد؟

طيب يبدو أن ... https://github.com/facebook/jest/commit/8a7b4a9df0759142d148cf2f69ec3f23457c542e؟

لم يكن الفارق بين 22 و 23 بمثابة كسر للصفقة بالنسبة لنا ، لذا فالتقسيم بين 24 و 23.6:

الالتزام | بارد | تحذير
- | - | -
25.0.0 | 87 | 53
24.9.0 | 81 | 52
24.7.1 | 88 | 55
24.0.0 | 86 | 84
fa0e81443 | 84 | 54
47cde7f24 | 84 | 52
bea5037a2 | 84 | 51
7d5de6844 | 83 | 53
ed6716787 | 83 | 53
8a7b4a9df | 84 | 52
7a64497a2 | 67 | 37
3abfa18d7 | 69 | 37
23.6.0 | 59 | 39

هل يمكنك تقديم التعليمات كيف قمت بالتقسيم؟ سيكون من المفيد حقا في المرة القادمة.

هذا مثير للاهتمام ، شكرًا @ nol13! هل تستخدم projects ؟ لن يؤثر هذا الالتزام نظريًا إلا على مشاريع متعددة. ولكن إذا كان يؤثر أيضًا على ذاكرة التخزين المؤقت الدافئة ، فهذا غريب جدًا. ربما أفسد شيء ما حول هذا المُعدّل بحثًا عن ذاكرة التخزين المؤقت؟ تم تغيير الكود المصدري في هذا الالتزام موجود الآن هنا ، إذا كنت تريد أن تتجول فيه: https://github.com/facebook/jest/blob/522ed17dcebf988450b93ddb8bf748249c75de82/packages/jest-transform/src/ScriptTransformer.ts

أيضا ، كيف يبدو 25.0.0 بالنسبة لك؟

امين
بالتأكيد ، أعتقد أن المشكلة الرئيسية التي كنت أواجهها قد تم حلها عن طريق تشغيل "إضافة الغزل والغزل -D -W @ babel / core babel-core @ bridge --ignore-scripts" كما هو مقترح أعلاه ، بعد التحقق من كل التزام وتثبيته .

أيضًا ، وقد يكون هذا بسبب شيء أفسدته في بيئتي المحلية ، لسبب ما لا يمكن تفسيره ، اضطررت إلى تغيير اسم المجلد الذي كان يوجد فيه ريبو المزاح المستنسخ وإلا ستكسر التحويلات. ../jest/jest = فشل ، ../jesty/jest = pass

بخلاف ذلك يتم اتباع تعليمات git-bisect من مستندات git. https://git-scm.com/docs/git-bisect

git clone https://github.com/facebook/jest.git
cd jest
yarn install;
git checkout v24.0.0;
git bisect start
git bisect bad
git checkout v23.6.0
git bisect good
yarn install
yarn && yarn add -D -W @babel/core babel-core<strong i="11">@bridge</strong> --ignore-scripts
cd ../myProject
../jest/jest

ثم مرة أخرى في مجلد الدعابة ، git bisect [bad/good] بناءً على النتيجة

SimenB لا لا تستخدم المشاريع. لقد أضفت 25.0.0 إلى الجدول أعلاه. لم يكن علميًا بشأن إغلاق جميع البرامج الأخرى ولكن يجب أن تكون دقيقة في الغالب. إذا كان يساعد ، التكوينات أدناه.

jest.config.js

module.exports = {
  clearMocks: true,
  setupFiles: ["dotenv/config"],
  setupTestFrameworkScriptFile: "./jest/setup.js",
  "snapshotSerializers": ["enzyme-to-json/serializer"],
  testRegex: "./src/test/.*Test[s]{0,1}.js(?!.snap)",
  testURL: "https://example.com",
  "moduleNameMapper": {
    "\\.(jpg|jpeg|png|gif|eot|otf|webp|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
  },
  "transform": {
    "^.+\\.jsx?$": "babel-jest"
  }
};

SimenB يسعدني تقديم المساعدة. أريد المحاولة مرة أخرى باستخدام خدعة yarn add -D -W @babel/core babel-core<strong i="6">@bridge</strong> --ignore-scripts .

هل لاحظت ما إذا كان الوقت المتزايد هو للاختبارات نفسها ، أو التمهيد؟

آسف ، لا أستطيع أن أقول.

هل يمكنك تقديم التعليمات كيف قمت بالتقسيم؟ سيكون من المفيد حقا في المرة القادمة.

@ mucsi96 كان المستند المساهم مفيدًا. أنا أستخدم وظيفة hyperfine و fish shell لبدء المقاييس وجدول بيانات لتسجيل القياسات.

SimenB :

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

المحتمل. لقد قمت بتلاعب بعض ملفات console.log () في ScriptTransformer لتثبيت الدعابة المحلي الخاص بي:

if (!projectCache) {
      console.log("No cache found.");
      projectCache = {
        configString: (0, _fastJsonStableStringify().default)(this._config),
        ignorePatternsRegExp: calcIgnorePatternRegExp(this._config),
        transformRegExp: calcTransformRegExp(this._config),
        transformedFiles: new Map()
      };
      projectCaches.set(config, projectCache);
    }else{
      console.log("Cache found");
    }

لم تتم طباعة Cache found ولو مرة واحدة أثناء تنفيذ الاختبار بالكامل. مشروع واحد فقط مع ألفي اختبار.

مثير للإعجاب! ماذا يحدث إذا فعلت projectCaches.set(stableStringify(config), projectCache); بدلاً من ذلك؟ قال thymikee إنهم قد لا يكونوا متطابقين بشكل مختلف ، مما يعني أننا سنفتقد دائمًا (وتسرب الذاكرة). ربما لا يكون stringify حلاً طويل المدى ، ولكن اختباره سيكون ممتعًا

SimenB سنحتاج إلى استخدام Map بدلاً من WeakMap بعد ذلك ، لأن السلاسل ليست مفاتيح صالحة للخرائط الضعيفة

نعم ، نقطة جيدة.

diff --git i/packages/jest-transform/src/ScriptTransformer.ts w/packages/jest-transform/src/ScriptTransformer.ts
index 6ee27c6dd..d91d661c7 100644
--- i/packages/jest-transform/src/ScriptTransformer.ts
+++ w/packages/jest-transform/src/ScriptTransformer.ts
@@ -43,10 +43,7 @@ const {version: VERSION} = require('../package.json');
 // This data structure is used to avoid recalculating some data every time that
 // we need to transform a file. Since ScriptTransformer is instantiated for each
 // file we need to keep this object in the local scope of this module.
-const projectCaches: WeakMap<
-  Config.ProjectConfig,
-  ProjectCache
-> = new WeakMap();
+const projectCaches = new Map<string, ProjectCache>();

 // To reset the cache for specific changesets (rather than package version).
 const CACHE_VERSION = '1';
@@ -74,17 +71,18 @@ export default class ScriptTransformer {
     this._transformCache = new Map();
     this._transformConfigCache = new Map();

-    let projectCache = projectCaches.get(config);
+    const stringifiedConfig = stableStringify(this._config);
+    let projectCache = projectCaches.get(stringifiedConfig);

     if (!projectCache) {
       projectCache = {
-        configString: stableStringify(this._config),
+        configString: stringifiedConfig,
         ignorePatternsRegExp: calcIgnorePatternRegExp(this._config),
         transformRegExp: calcTransformRegExp(this._config),
         transformedFiles: new Map(),
       };

-      projectCaches.set(config, projectCache);
+      projectCaches.set(stringifiedConfig, projectCache);
     }

     this._cache = projectCache;

ربما يكون الاحتفاظ بالتسجيل الذي تقوم به بالفعل فكرة جيدة أيضًا في حالة عدم حدوث أي فرق

يؤدي ذلك إلى إصابة ذاكرة التخزين المؤقت - ولكن لا يبدو أنها تحسن الأداء ولو قليلاً.

كنت أظن أن Stringify سيكون السبب ، ولكن حتى استخدام "A" كمفتاح لا يجعله يعمل بشكل أسرع.

ثم استخدمت كائنًا عاديًا بشكل مباشر. علاء if (!projectChace ) { projectCache = ... } . حتى هذا لم يكن له نعمة الأداء.

أعتقد أنه يمكنك اقتلاع شيء التخزين المؤقت بالكامل دون أي تأثير سيء. بالنظر إلى أنه أ) لم يعمل طوال هذا الوقت على أي حال وب) لا يبدو أنه يساعد في الأداء حتى لو نجح.

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

StringEpsilon هل يتخلص من مساعدة projectCaches من تلقاء نفسه؟

لست متأكدا مما تقصده. لم أحاول نسخ آلية التخزين المؤقت بالكامل / التراجع عن الالتزام (لأنني أقوم بإصلاح عقدة node_modules الخاصة بي). لكن عندما حاولت استخدام الكائن العادي ، استبدلت const projectCaches = new Map() بـ let projectCache = null . بلا تأثير.

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

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

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

diff --git i/packages/jest-transform/src/ScriptTransformer.ts w/packages/jest-transform/src/ScriptTransformer.ts
index 6ee27c6dd..d00996c62 100644
--- i/packages/jest-transform/src/ScriptTransformer.ts
+++ w/packages/jest-transform/src/ScriptTransformer.ts
@@ -30,23 +30,13 @@ import {
 import shouldInstrument from './shouldInstrument';
 import enhanceUnexpectedTokenMessage from './enhanceUnexpectedTokenMessage';

-type ProjectCache = {
-  configString: string;
-  ignorePatternsRegExp?: RegExp;
-  transformRegExp?: Array<[RegExp, string, Record<string, unknown>]>;
-  transformedFiles: Map<string, TransformResult>;
-};
-
 // Use `require` to avoid TS rootDir
 const {version: VERSION} = require('../package.json');

-// This data structure is used to avoid recalculating some data every time that
-// we need to transform a file. Since ScriptTransformer is instantiated for each
-// file we need to keep this object in the local scope of this module.
-const projectCaches: WeakMap<
-  Config.ProjectConfig,
-  ProjectCache
-> = new WeakMap();
+const cache: Map<string, TransformResult> = new Map();
+const configToJsonMap = new Map();
+// Cache regular expressions to test whether the file needs to be preprocessed
+const ignoreCache: WeakMap<Config.ProjectConfig, RegExp | null> = new WeakMap();

 // To reset the cache for specific changesets (rather than package version).
 const CACHE_VERSION = '1';
@@ -64,7 +54,6 @@ async function waitForPromiseWithCleanup(

 export default class ScriptTransformer {
   static EVAL_RESULT_VARIABLE: 'Object.<anonymous>';
-  private _cache: ProjectCache;
   private _config: Config.ProjectConfig;
   private _transformCache: Map<Config.Path, Transformer>;
   private _transformConfigCache: Map<Config.Path, unknown>;
@@ -73,21 +62,6 @@ export default class ScriptTransformer {
     this._config = config;
     this._transformCache = new Map();
     this._transformConfigCache = new Map();
-
-    let projectCache = projectCaches.get(config);
-
-    if (!projectCache) {
-      projectCache = {
-        configString: stableStringify(this._config),
-        ignorePatternsRegExp: calcIgnorePatternRegExp(this._config),
-        transformRegExp: calcTransformRegExp(this._config),
-        transformedFiles: new Map(),
-      };
-
-      projectCaches.set(config, projectCache);
-    }
-
-    this._cache = projectCache;
   }

   private _getCacheKey(
@@ -95,7 +69,12 @@ export default class ScriptTransformer {
     filename: Config.Path,
     instrument: boolean,
   ): string {
-    const configString = this._cache.configString;
+    if (!configToJsonMap.has(this._config)) {
+      // We only need this set of config options that can likely influence
+      // cached output instead of all config options.
+      configToJsonMap.set(this._config, stableStringify(this._config));
+    }
+    const configString = configToJsonMap.get(this._config) || '';
     const transformer = this._getTransformer(filename);

     if (transformer && typeof transformer.getCacheKey === 'function') {
@@ -146,13 +125,9 @@ export default class ScriptTransformer {
   }

   private _getTransformPath(filename: Config.Path) {
-    const transformRegExp = this._cache.transformRegExp;
-    if (!transformRegExp) {
-      return undefined;
-    }
-
+    const transformRegExp = this._config.transform;
     for (let i = 0; i < transformRegExp.length; i++) {
-      if (transformRegExp[i][0].test(filename)) {
+      if (new RegExp(transformRegExp[i][0]).test(filename)) {
         const transformPath = transformRegExp[i][1];
         this._transformConfigCache.set(transformPath, transformRegExp[i][2]);

@@ -402,7 +377,7 @@ export default class ScriptTransformer {
     if (!options.isCoreModule) {
       instrument = shouldInstrument(filename, options, this._config);
       scriptCacheKey = getScriptCacheKey(filename, instrument);
-      const result = this._cache.transformedFiles.get(scriptCacheKey);
+      const result = cache.get(scriptCacheKey);
       if (result) {
         return result;
       }
@@ -416,7 +391,7 @@ export default class ScriptTransformer {
     );

     if (scriptCacheKey) {
-      this._cache.transformedFiles.set(scriptCacheKey, result);
+      cache.set(scriptCacheKey, result);
     }

     return result;
@@ -514,9 +489,22 @@ export default class ScriptTransformer {
   }

   shouldTransform(filename: Config.Path): boolean {
-    const ignoreRegexp = this._cache.ignorePatternsRegExp;
-    const isIgnored = ignoreRegexp ? ignoreRegexp.test(filename) : false;
+    if (!ignoreCache.has(this._config)) {
+      if (
+        !this._config.transformIgnorePatterns ||
+        this._config.transformIgnorePatterns.length === 0
+      ) {
+        ignoreCache.set(this._config, null);
+      } else {
+        ignoreCache.set(
+          this._config,
+          new RegExp(this._config.transformIgnorePatterns.join('|')),
+        );
+      }
+    }

+    const ignoreRegexp = ignoreCache.get(this._config);
+    const isIgnored = ignoreRegexp ? ignoreRegexp.test(filename) : false;
     return (
       !!this._config.transform && !!this._config.transform.length && !isIgnored
     );
@@ -643,34 +631,6 @@ const getScriptCacheKey = (filename: Config.Path, instrument: boolean) => {
   return filename + '_' + mtime.getTime() + (instrument ? '_instrumented' : '');
 };

-const calcIgnorePatternRegExp = (config: Config.ProjectConfig) => {
-  if (
-    !config.transformIgnorePatterns ||
-    config.transformIgnorePatterns.length === 0
-  ) {
-    return undefined;
-  }
-
-  return new RegExp(config.transformIgnorePatterns.join('|'));
-};
-
-const calcTransformRegExp = (config: Config.ProjectConfig) => {
-  if (!config.transform.length) {
-    return undefined;
-  }
-
-  const transformRegexp: Array<[RegExp, string, Record<string, unknown>]> = [];
-  for (let i = 0; i < config.transform.length; i++) {
-    transformRegexp.push([
-      new RegExp(config.transform[i][0]),
-      config.transform[i][1],
-      config.transform[i][2],
-    ]);
-  }
-
-  return transformRegexp;
-};
-
 const wrap = (content: string, ...extras: Array<string>) => {
   const globals = new Set([
     'module',

SimenB تم تطبيق عودتك على 24.9.0 يعيدنا إلى ~ 35 ثانية! لذلك تقريبًا ما نراه في 23.6.0.

لطيف! هل تستخدم مشاريع متعددة؟

تحرير: انتظر ، لقد سألت بالفعل عن ذلك ... ممتع للغاية. ماذا عن التصحيح الأول الذي قمت بنشره (والذي يستبدل الخريطة الضعيفة بخريطة ويضبط التكوين على أنه المفتاح)؟

نعم ، أرى تسريعًا مشابهًا مع ذلك أيضًا!

شيء مختلف مع مشروعنا / التكوين مقابل StringEpsilon لجعله يتصرف مثل "المشاريع" قيد الاستخدام؟

لا أعرف ... أنا غير قادر على إنتاج خطأ في ذاكرة التخزين المؤقت مقابل نتيجة ذاكرة التخزين المؤقت التي تختلف مع هذا التصحيح وبدونه ، مع أو بدون projects ومع أو بدون runInBand . أحصل على نفس القدر من الضربات والإخفاقات بغض النظر. للتحقق من أنه يتعلق بذاكرة التخزين المؤقت مرة / فشل على الإطلاق ، هل يمكنك إضافة بعض التسجيل؟

diff --git i/packages/jest-transform/src/ScriptTransformer.ts w/packages/jest-transform/src/ScriptTransformer.ts
index 6ee27c6dd..432ec39c9 100644
--- i/packages/jest-transform/src/ScriptTransformer.ts
+++ w/packages/jest-transform/src/ScriptTransformer.ts
@@ -76,7 +76,10 @@ export default class ScriptTransformer {

     let projectCache = projectCaches.get(config);

-    if (!projectCache) {
+    if (projectCache) {
+      console.log('hit!', config.name);
+    } else {
+      console.log('miss!', config.name);
       projectCache = {
         configString: stableStringify(this._config),
         ignorePatternsRegExp: calcIgnorePatternRegExp(this._config),

مع وبدون تغيير WeakMap -> Map . ربما لا تحتاج إلى الجزء config.name حيث يجب أن يكون مستقرًا

جميع الضربات وسريعة مع التصحيح ، وكلها تفوت وبطيئة بدون.

قد أحتاج إلى إعادة زيارة الاختبارات وبناء الدعابة بشكل صحيح ، بدلاً من monkeypatching @jest/transform في مجلد node_modules الخاص بي.

لكن @ nol13 : ما هو نظام التشغيل الذي تستخدمه

ماك. نعم windows def أبطأ ، لم تختبر الفرق هناك رغم ذلك ، يمكن المحاولة الأسبوع المقبل. كان الحفاظ على الأوقات المعقولة على أجهزة Windows غير النازفة هو مصدر قلقه الرئيسي.

كان مشروعي يستخدم المشروع القديم jest-dom/extend-expect ، لذلك قمت باستبداله بـ @testing-library/jest-dom/extend-expect وقمت بترقيته إلى 24.9.0 ، والآن أصبحت الاختبارات والتغطية سريعة للغاية.

على النوافذ التي تحتوي على العقدة 10 وذاكرة التخزين المؤقت الدافئة:

85s بدون رقعة
56s مع التصحيح

هذا مذهل! SimenB ما هي احتمالات جعل هذا في جزء ثانوي / رقعة من 24؟

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

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

https://github.com/nol13/jest-test-repo

^ هذا مثال بسيط. بدون التصحيح ، هذا يضرب مع runInBand لكنه يخطئ بدونه.

شكرا لك! سأبحث في هذا لاحقًا اليوم. للتحقق من افتراضاتي - هذا سريع في 23 ، الترقية إلى 24 أو 25 بطيئة ، لكن تطبيق التصحيح يجعل تلك قابلة للمقارنة بـ 23 مرة أخرى؟

ما أراه (أكثر من 10 أشواط مع تشغيل الإحماء للذاكرة المؤقتة)

| نسخة الدعابة | الوقت |
| ------------ | ---: |
| 23.6 | 6.2 ثانية |
| 24.9 | 8.5 ثانية |
| 24 ث / رقعة | 6.7 ثانية |
| 25 | 8.0s |
| 25 ث / رقعة | 6.5 ثانية |

يمكنني أيضًا إعادة إنتاج الضربة مقابل الخطأ في التخزين المؤقت. شكرا على Repro الرائع @ nol13! سآخذ التصحيح لاحقًا اليوم

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

PR: # 8890

هذه الحالة مع ضرب ذاكرة التخزين المؤقت وفقدانها تزعجنا كثيرًا. هل هناك أي وقت متوقع للوصول للعلاقات العامةSimenB؟

نأمل اليوم. نحتاج فقط للتأكد من أنه يعمل مع FB (أفضل اختبار لم يتم كسر أي شيء موجود)

يمكنك استخدام patch-package في هذه الأثناء. فرق:

diff --git a/node_modules/@jest/transform/build/ScriptTransformer.js b/node_modules/@jest/transform/build/ScriptTransformer.js
index 8b02912..2191456 100644
--- a/node_modules/@jest/transform/build/ScriptTransformer.js
+++ b/node_modules/@jest/transform/build/ScriptTransformer.js
@@ -199,7 +199,7 @@ const {version: VERSION} = require('../package.json'); // This data structure is
 // we need to transform a file. Since ScriptTransformer is instantiated for each
 // file we need to keep this object in the local scope of this module.

-const projectCaches = new WeakMap(); // To reset the cache for specific changesets (rather than package version).
+const projectCaches = new Map(); // To reset the cache for specific changesets (rather than package version).

 const CACHE_VERSION = '1';

@@ -224,16 +224,17 @@ class ScriptTransformer {
     this._config = config;
     this._transformCache = new Map();
     this._transformConfigCache = new Map();
-    let projectCache = projectCaches.get(config);
+    const configString = (0, _fastJsonStableStringify().default)(this._config);
+    let projectCache = projectCaches.get(configString);

     if (!projectCache) {
       projectCache = {
-        configString: (0, _fastJsonStableStringify().default)(this._config),
+        configString,
         ignorePatternsRegExp: calcIgnorePatternRegExp(this._config),
         transformRegExp: calcTransformRegExp(this._config),
         transformedFiles: new Map()
       };
-      projectCaches.set(config, projectCache);
+      projectCaches.set(configString, projectCache);
     }

     this._cache = projectCache;

SimenB هذا التصحيح هو إصدار الدعابة؟ 25.0.0 أو 24.9.0؟

1. هذا هو 24.9

diff --git a/node_modules/@jest/transform/build/ScriptTransformer.js b/node_modules/@jest/transform/build/ScriptTransformer.js
index 0dbc1d7..b595ec6 100644
--- a/node_modules/@jest/transform/build/ScriptTransformer.js
+++ b/node_modules/@jest/transform/build/ScriptTransformer.js
@@ -207,7 +207,7 @@ const _require = require('../package.json'),
 // we need to transform a file. Since ScriptTransformer is instantiated for each
 // file we need to keep this object in the local scope of this module.

-const projectCaches = new WeakMap(); // To reset the cache for specific changesets (rather than package version).
+const projectCaches = new Map(); // To reset the cache for specific changesets (rather than package version).

 const CACHE_VERSION = '1';

@@ -239,16 +239,17 @@ class ScriptTransformer {
     this._config = config;
     this._transformCache = new Map();
     this._transformConfigCache = new Map();
-    let projectCache = projectCaches.get(config);
+    const configString = (0, _fastJsonStableStringify().default)(this._config);
+    let projectCache = projectCaches.get(configString);

     if (!projectCache) {
       projectCache = {
-        configString: (0, _fastJsonStableStringify().default)(this._config),
+        configString,
         ignorePatternsRegExp: calcIgnorePatternRegExp(this._config),
         transformRegExp: calcTransformRegExp(this._config),
         transformedFiles: new Map()
       };
-      projectCaches.set(config, projectCache);
+      projectCaches.set(configString, projectCache);
     }

     this._cache = projectCache;

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

شكرا لكل من ساعد في تعقب هذا!

SimenB قلت "إصدار جديد من 25 سيأتي الأسبوع المقبل." هل من أخبار عن الإصدار؟

شكر

آخر ما سمعته أنه يجري اختباره في FB يوم الجمعة.

هل سيكون من الممكن إصدار تصحيح للإصدار 24 بينما ننتظر إصدار الإصدار 25؟

مرحبا SimenB !

شكرا على التصحيح 24.9!

أحاول استخدام patch-package لتصحيح مشروعنا في هذه الأثناء وقمت بتحديث node_modules/@jest/transform/build/ScriptTransformer.js مع الفرق.

ومع ذلك ، عندما أقوم بتشغيل yarn patch-package jest ، فإنه لا يوجد فرق (ربما لأن المسار من الناحية الفنية هو node_modules/@jest بدلاً من node_modules/jest . لكن إذا قمت بتشغيل yarn patch-package @jest ، ثم تقول أن @jest ليس في package.json

أي مؤشر لهذا الموقف؟ شكرا جزيلا!

جمعة سعيدة للجميع! فقط أتساءل عما إذا كان لدى أي شخص نصائح حول كيفية تصحيح jest 24.9 باستخدام الإصلاح باستخدام patch-package 🙏 شكرًا لك!

أي تقدم في إطلاق هذا؟

تحديث سريع على https://github.com/facebook/jest/issues/7811#issuecomment -540128239 و https://github.com/facebook/jest/issues/7811#issuecomment -541189080 ، قال @ ds300 أنه كان علينا فقط فعل: yarn patch-package @jest/transform 🎉!

يمكن تأكيد عمل التصحيح SimenB لـ 24.9 !!

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

شكرا لكل من ساعد في تعقب هذا!

أي تحديث على هذا بأي فرصة؟

كل ما أريده لعيد الميلاد هو y ... Jest 25 <3

إذا تأخر Jest 25 لسبب ما ، فهل سيكون من الممكن تحرير تصحيح لـ 24.9 مع الإصلاح؟ تضمين التغريدة

للتسجيل ، كان jest @ next الذي تم تنزيله في 22 تشرين الثاني (نوفمبر) بطيئًا للغاية ، لكنني أعدت التنزيل الآن ويبدو أنه أسرع كثيرًا (آسف لعدم الدقة)

dpinol فضولي ما هو الإصدار الذي نجح ؟ يبدو أن الإصدار الموجود في سجل npm الذي تم وضع علامة عليه كـ 25.0.0 يشير إلى https://github.com/facebook/jest/commit/ff9269be05fd8316e95232198fce3463bf2f270e والذي كان قبل هبوط perf fix. بالنظر إلى الكود الموجود على unpkg لـ 25.0.0 (وهو ما تحصل عليه عند تثبيت jest@next ) ، لم يتم تطبيق الإصلاح: https://unpkg.com/browse/@jest/transform @ 25.0 .0 / build / ScriptTransformer.js

SimenB هل هناك أي إصدار من المزاح (إما v25 + أو v24 مصحح) متوفر في السجل حاليًا والذي يتضمن هذا الإصلاح؟ أثناء استخدام شيء مثل حزمة التصحيح أمر ممكن ، أفضل عدم إنشاء نسخة مخصصة أو تفرع منها نظرًا لأن الإصلاح موجود بالفعل في الإصدار الرئيسي. إذا لم يكن الأمر كذلك ، فربما يكون أبسط خيار من نهايتك هو تحديث علامة jest@next للإشارة إلى الإصدار 25.0.1 الجديد أو ما شابه ، ومن ثم يمكن للمطورين الراغبين في الاشتراك في بنية غير مستقرة القيام بذلك على الأقل ؟

بالنسبة للأشخاص الذين يرغبون في استخدام patch-package اليوم ، يجب أن تعمل الخطوات التالية 🤞

خطوات:

1. تحديث package.json :

 "scripts": {
+  "postinstall": "patch-package"
 }

1. احصل على patch-package في package.json [ doc ]:
   $yarn add patch-package postinstall-postinstall أو $npm i patch-package

2. انتقل إلى جذر مشروعك ، وافتح الملف node_modules/@jest/transform/build/ScriptTransformer.js في المحرر المفضل لديك

3. تحديث الكود حسب الفروق:
   jest 24.9 : https://github.com/facebook/jest/issues/7811#issuecomment -527347645
   jest 25 : https://github.com/facebook/jest/issues/7811#issuecomment -527107215

4. yarn patch-package @jest/transform أو npx patch-package @jest/transform .
   إذا نجحت ، فسترى Created file patches/@jest+transform+24.9.0.patch

5. يمكنك الآن اختبار التصحيح بواسطة $rm -rf node_modules && yarn install ، و patch-package يجب تصحيح الفرق لك تلقائيًا

6. تأكد من الالتزام بـ patches/@jest+transform+24.9.0.patch ، حتى يحصل الجميع على التصحيح ، بما في ذلك خط أنابيب CI / CD!

متى سيكون هذا في بيان؟

رن 24.9 مقابل 25.1 في مجموعة اختبار محلية. عمل مذهل SimenB والأصدقاء!

Jest 25.1.2 تحديث

البرد:

مجموعات الاختبار: تم تخطي 3 ، وتم تخطي 218 ، وإجمالي 218 من 221
الاختبارات: تم تخطي 12 ، اجتياز 962 ، المجموع 974
لقطات: تم تمرير 17 ، المجموع 17
الوقت: 46.692 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حررت في 47.55 ثانية.

دافئ:

مجموعات الاختبار: تم تخطي 3 ، وتم تخطي 218 ، وإجمالي 218 من 221
الاختبارات: تم تخطي 12 ، اجتياز 962 ، المجموع 974
لقطات: تم تمرير 17 ، المجموع 17
الوقت: 32.527 ثانية ، يقدر بـ 44 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حرر في 33.65 ثانية.

الدعابة 24.9.2

البرد:

مجموعات الاختبار: تم تخطي 3 ، وتم تخطي 218 ، وإجمالي 218 من 221
الاختبارات: تم تخطي 12 ، اجتياز 962 ، المجموع 974
لقطات: تم تمرير 17 ، المجموع 17
الوقت: 68.89 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حرر في 70.14 ثانية.

دافئ:

مجموعات الاختبار: تم تخطي 3 ، وتم تخطي 218 ، وإجمالي 218 من 221
الاختبارات: تم تخطي 12 ، اجتياز 962 ، المجموع 974
لقطات: تم تمرير 17 ، المجموع 17
الوقت: 57.806 ثانية ، يقدر بـ 65 ثانية
تم تشغيل جميع أجنحة الاختبار.
✨ حرر في 58.92 ثانية.

كنت على وشك أن أنشر أنه تم إطلاق Jest 25 المستقر للتو ، وقد اختبرته بالفعل 😀

أرقام رائعة ، شكرًا لمشاركةcsvan!

لست متأكدًا مما إذا كان يجب تقديم هذا كمسألة منفصلة في هذه المرحلة ، ولكن للأسف ، لا يبدو أن 25.1.0 قد حلت التباطؤ بالنسبة لنا. لقد تخطينا الإصدار 24 بسبب التباطؤ الذي رأيناه من 23.4.2. بالنسبة للتطبيق بأكمله (130 ملف اختبار ، 1104 اختبارًا) أرى أن الاختبارات تنتقل من 17-18 ثانية في الإصدار 23 إلى أخذ 23-24 ثانية في الإصدار 25. انتقل تشغيل أبطأ ملف اختبار في تطبيقنا بمفرده من 6 ثوانٍ في الإصدار 23 إلى 8 ثوانٍ في الإصدار 25.

مثير للاهتمام ، هل ستتمكن من نشر نسخة في عدد جديد؟ كانت هذه المشكلة على وجه الخصوص حول خطأ معين تم تقديمه في Jest 24 والذي تم إصلاحه في # 8890

هناك مشكلة جديدة لمشكلات أداء Jest 25: https://github.com/facebook/jest/issues/9457