Было бы здорово, если бы вы могли прикрепить репродукцию, которую можно было бы проверить и проанализировать.

Мы также наблюдаем довольно существенное снижение производительности 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 с.
Сейчас 13: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

Чтобы быть более полезным, я провел статистику. К сожалению, 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 с
--no-cache | 8,6 с
--no-cache --maxWorkers = 2 | 6,8 с
--runInBand | 3,8 с
--runInBand --no-cache | 8,3 с

[email protected] :

Пройденные варианты | ВРЕМЯ
- | -
(без вариантов) | 4,4 с
--maxWorkers = 2 | 4,7 с
--no-cache | 13,4 с
--no-cache --maxWorkers = 2 | 17,6 с
--runInBand | 5,1 с
--runInBand --no-cache | 9,3 с

Проверено на тестах этого репо https://github.com/LambdaSchool/React-Testing , результаты:
v23:
`` node_modules / .bin / jest --verbose
ПРОЙДИТЕ src / __ tests __ / App.spec.js

✓ рендеринг без сбоев (13 мс)

ПРОЙДИТЕ src / __ tests __ / Panel.spec.js

✓ рендеринг без сбоев (13 мс)

ПРОЙДИТЕ src / __ tests __ / Display.spec.js

✓ рендеринг без сбоев (14 мс)

ПРОЙДИТЕ src / __ tests __ / 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.

Тем не менее, подробный режим не обеспечивает согласованных таймингов, однако в неполном режиме v24 в среднем на 1 секунду медленнее, чем v23 (3,9 с против 4,9 с на моей машине).
Вот архив с двумя настройками https://www.dropbox.com/s/mgbviexw96l2o1z/JestReact-Testing%2023vs24.zip?dl=0

@thymikee Можно ли здесь удалить Windows-тег? Это определенно присутствует в MacOS и Ubuntu.

Есть v24:

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

Это v23:

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

Ого, 17 против 113, это здорово! Есть ли возможность поделиться этим проектом?

Я думаю, нам нужно серьезно подумать о добавлении мониторинга производительности в Jest. @aaronabramov рассказывал об этом в # 4471. Node поставляется с тем же API производительности, что и браузер (доступен с узла 8): https://nodejs.org/api/perf_hooks.html , может быть, мы можем использовать это для измерения? Вероятно, первым шагом должно быть наличие способа определить, сколько времени занимает разные вещи (так # 4471, но это говорит только о том, что происходит внутри тестов)

Конечно, это репо .

В настоящее время я не хочу обновляться до v24 из-за этой разницы 😞

Благодаря!

На моей машине это занимает 35-40 секунд в холодном кэше и 7-8 секунд в теплом. С jest 24 я получаю 40-45 секунд для холодного кеша и 17-18 секунд для теплого кеша. Определенно показывает проблему (хотя и не такую ​​серьезную, как на вашей машине). Я постараюсь найти время, чтобы разобраться в этом

В настоящее время я не хочу обновляться до v24 из-за этой разницы

Понятно!

Возможно, я запускал 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 | 126s | 145s | + 16%

Еще хуже разница между jest и jest --no-cache

версия | шутка (горячий кеш) | шутка --no-cache | разница
--- | --- | --- | ---
23.6.0 | 59s | 113s | + 92%
24.1.0 | 144s | > 400 с | +> 200%
24.8.0 | 126s | 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. для write-file-atomic, что, безусловно, не идеально ...

Существует №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 в папку test

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

и в package.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), что значительно улучшило время тестирования.

Я подумываю вернуться к шутке 23, пока она не исправлена, для меня это примерно в 3-5 раз медленнее, чем раньше.

Самый быстрый выпуск шутки - 22.4.4 . Все более новые версии были намного медленнее.

@deleteme чем v23 по сравнению с v22 ? Разница в скорости значительная? Я хочу предложить перейти на более раннюю версию до 22 но мой коллега сказал, что версия слишком низкая (по сравнению с 24 )

Привет! Я не хочу увеличивать шум, связанный с этой проблемой, поэтому я сохраню простоту и добавлю еще одно воспроизведение с открытым исходным кодом:

Проект с большим размером кода (в частности, один сгенерированный лексер размером 2 мегабайта), где одно изменение обновления Jest 23.0.x до Jest v24.0.x привело к скачку времени тестирования с ~ 7 секунд (~ 5 секунд на тестовый файл) до ~ 147 (~ 70 секунд на каждый тестовый файл). Да, регресс 2000% . 🤯

Проект ELLIOTTCABLE / excmd.js; совершить ELLIOTTCABLE / excmd. js @ f0982114 использует Jest 23 и постоянно сообщает о времени выполнения <10 секунд на jest --clearCache && time jest ; следующий коммит, ELLIOTTCABLE / excmd. js @ d4d3a08d , обновляет Jest до v24 и показывает согласованное время очистки кеша ≥100 с.

Опять же, так что это не ускользает - я сильно подозреваю, что снижение производительности как-то связано с копированием файловой системы или загрузкой модуля; потому что то, что делает мой проект особенным, - это загрузка одного сложного двухмегабайтного файла .js . (Несвязанная ошибка.)

Я также не уверен, что это связано с Вавилоном; Babel с радостью деоптимизирует стиль этого файла и продолжает свой веселый путь, показывая время сборки настенных часов 4.48s .

(Поскольку я уверен, что эта проблема вызывает стресс (много пользователей жалуются, ее трудно воспроизвести, она связана с производительностью и, следовательно, трудна для отладки…), я хотел бы добавить: мы любим Jest и вашу тяжелую работу по обслуживанию. , даже если вы говорите «нет», мы очень ценим его. ❤️)

@ronayumik Начиная с Jest 22.4.4, по мере выпуска новых версий Jest и когда я заинтересован в обновлении, я сравниваю, сколько времени требуется для запуска наших тестов (412 наборов тестов, тесты 2015 года).

Следующая суть включает несколько тестов с использованием Jest 22, 23 и 24.

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

До сих пор каждая новая версия была значительно медленнее.

@deleteme пробовали ли вы

@thymikee Нет. Вы хотите, чтобы я

Нет, вы можете просто использовать разрешения пряжи

@thymikee Я обновил суть своих тестов, включив в него сравнение jest @ 24.8.0 с разрешением пряжи micromatch

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

Это все еще довольно плохо: / Все еще чувствую, что что-то не так с jest-runtime, но я не понимаю, что

Это не шутка. Речь идет о Вавилоне 7.
Мы обновили babel 6 до 7 в нашем проекте и получили снижение производительности компоновки примерно на 30% для той же кодовой базы.

@smelukov Это интересная возможность, я об этом раньше не думал. Учитывая, что эти проблемы с производительностью редко имеют единственную причину или решение, Babel действительно может быть другим фактором. Удалось ли вам сделать это воспроизводимым в меньшем масштабе и сообщить о проблеме с Babel?

@smelukov Наш Babel время компиляции быстрее с 7, но Jest медленнее.

Изменить: Также, если я не ошибаюсь, замедление Babel повлияет только на некэшированные сборки, но мы видим это и для кешированных сборок.

@jeysal Я
Я доложу, когда закончу;)

@agrasley мы используем кешированную сборку

Мы вышли из Babel (теперь полностью TS с ts-jest) и увидели эту регрессию с 23 до 24 (+ 40% увеличение времени для кешированных тестов, + 100% для некэшированных тестов). Память тоже увеличивается. Привязка микроматчей к 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 и проверка типов включена ("isolatedModules": false)
Разрешение пряжи micromatch 4.0.2 нам тоже не помогло.

Вскоре попробую последнюю версию (24.8.0) и доложу.

РЕДАКТИРОВАТЬ: так же медленно на 24.8.0. У кого-нибудь есть обходной путь? У нас есть ~ 5500 тестов, и мы буквально не можем запустить их в последней версии (умирает в CI из-за тайм-аутов или занимает всю вечность (20+ минут) по сравнению с 3 минутами, которые раньше занимали).

Я собираюсь взглянуть на исходный код и сделать несколько различий, чтобы увидеть, что я могу найти. Возможно, я смогу хотя бы начать с некоторой помощи.

Если кто-то уже начал пинговать или отвечать в этой теме, очень любите.

Надеюсь, я заметил некоторые места, которые замедляют jest 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. Мы будем обновлять микроматч в jest 25.
2. Я боялся, что желание собрать стеки негативно скажется на производительности: https://github.com/facebook/jest/pull/6965#issuecomment -421612367. Не уверен, что здесь делать - стеки важны для понимания того, что пошло не так, если тесты не пройдут. Может быть, мы могли бы добавить для него опцию, чтобы люди могли выбрать более качественные трассировки? Что они будут активировать, когда тесты не смогут (потенциально) получить лучшую трассировку
3. Я немного удивлен изменением красивого формата - я не ожидал, что это будет сложно, поскольку большую часть времени выбрасываются Error s, а этот путь кода не активирован.

Включение звучит как хорошая идея - так я могу быстро запускать jest на ci и более подробный локально, когда я действительно хочу что-то отладить.

@vitalibozhko, предполагая, что я правильно связываю вашу ветку, для меня более или менее похоже на 24.8.0. Мне кажется, что в первый раз, когда я запустил его, он был быстрее, так что, возможно, что-то там не так, но теперь я постоянно вижу примерно то же время, что и 24.8.0. В любом случае уверен, что он использует сборку из вашей ветки. Просто перешел на jest, поэтому в большинстве наших тестов по-прежнему используются chai-expect и sinon, если это важно.

260 наборов / 1583 тестов / четырехъядерный процессор с битрейтом / 2-е время выполнения

22.4.4: 47 с
23.6.0: 54 с
24.8.0: 72 с
24.8.0-перф. Точек: 72 с

Изменить: версия узла, похоже, также имеет большое влияние на это, переход к узлу 10 с узла 8 занимает 10-15 секунд от указанного выше времени.

(Я тоже пытался протестировать последнюю мастер-фиксацию, но получал синтаксические ошибки, и все еще получал те же ошибки, когда я вернулся, чтобы повторно связать ветку Виталибожко, и мне больше не хочется возиться с этим, так что ...)

@SimenB

Я вижу 3 основных изменения

Перейти на micromatch @ 4
Переместить коллекцию стека (может быть, даже удалить? Я только что просмотрел)
Не используйте красивый формат для форматирования выданных без ошибок
Это кажется правильным?

Выглядит правильно

какие части оказали наибольшее влияние?

Я бы сказал, что наиболее заметное влияние оказывает потребность в «тяжелых» модулях, таких как pretty-format, даже если они необходимы только при определенных обстоятельствах (например, в спецификации используются снимки состояния, в неудачных спецификациях требуется форматирование ошибки и т. Д.). Внесенные изменения были наиболее очевидными местами на диаграмме профиля пламени.
С точки зрения загрузки ЦП есть одна очевидная вещь - getAllCoverageInfo с использованием deepCyclicCopyObject (7% от общего времени), замененного на JSON.parse (JSON.stringify ()), он отлично подходит для клонирование покрытия - в случае моего проекта это сокращает общее время клонирования с 2,3 до 0,4 с

Я боялся, что желание собрать стеки отрицательно скажется на perf: # 6965 (комментарий). Не уверен, что здесь делать - стеки важны для понимания того, что пошло не так, если тесты не пройдут. Может быть, мы могли бы добавить для него опцию, чтобы люди могли выбрать более качественные трассировки? Что они будут активировать, когда тесты не смогут (потенциально) получить лучшую трассировку

Вернул коллекцию стека - получил плюс 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.

Мы используем jest для тестирования нашего приложения Angular 8 с помощью babel-jest и ts-jest. Раньше мы запускали наши 200 тестов менее чем за 5 минут на hest 23, а теперь с 24.9 это более 20 минут, что совершенно неприемлемо. Я использую узел 10. Время больше как для холодного старта, так и с кешем.

Есть ли на данный момент обходной путь, кто-нибудь активно работает над решением этой проблемы? @SimenB @thymikee ? По мере того, как становится все более очевидным, что эта проблема с производительностью начинает мешать большинству пользователей.

Это ужасный регресс 🙁 Ваш проект с открытым исходным кодом?

Вы пробовали ветку из 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

@dmitriivikorchuk

после этого вопроса про открытый исходный код / ​​нет и тишина.

Что ж, наличие доступа к нетривиальному проекту, в котором проблема легко воспроизводится, конечно же, помогает выяснить, почему это происходит. Но что я знаю.

Что касается «тишины», я почти уверен, что команда не нанята для работы над Jest и так же занята своей повседневной работой, как и мы с вами. Это проект с открытым исходным кодом, ничто не мешает вам разобраться в проблеме самостоятельно.

Я не пытаюсь быть неблагодарным (спасибо всем за вклад: P), но просто говорю, что если кто-то работает над этим, снижение производительности, вероятно, должно быть приоритетом по сравнению с добавлением каких-либо новых функций. Я предполагаю, что многие другие тоже останутся на 22 или 23 в настоящее время.

Большинство (любые?) Кодовых баз не сталкиваются с этой проблемой? Большинству людей просто все равно?

В каком состоянии Jest использует кеш? Сегодня вытащил новый код из репо, и хотя у меня есть соответствующий каталог кеша, Jest не хочет его использовать. Запуск тестов занимает столько же, сколько чистый запуск без кеша.

Кеш @tscislo включен по умолчанию и должен работать, если вы его не переопределите.

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

@csvan спасибо, но у меня это работает не так

@tscislo Как выглядит ваша конфигурация шутки?

По теме: Из вещей, упомянутых в этой проблеме, которые помогают, мы достигли 2: мы отказались от узла 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, поэтому любое потраченное время - это либо свободное время, либо время, потраченное на дневную работу вместо того, чтобы делать то, за что нам платят. Иногда то, что нужно моей повседневной работе, частично совпадает с тем, что Jest может делать лучше (на работе мы используем 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. Но наличие трех вызовов против 22 require() в любом случае должно немного помочь.

Мы определенно можем попробовать объединить наши модули и посмотреть, имеет ли это значение! По крайней мере, те, которые требуются внутри песочницы. В настоящее время мы связываем браузер, но это включает в себя зависимости - я думаю, здесь мы сохраним их внешними.

Возвращаясь к этому снова: я подозреваю, что обычный require Node имеет много оптимизации, которую мы упускаем, потому что require действительно происходит от jest-runtime . Возможно, в этом можно убедиться, посмотрев, сколько времени требуется для загрузки деревьев модулей в обычном узле по сравнению со средой выполнения 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

... и, конечно же, закрытое репо :)

Первоначально эти тесты занимали ... 4 мин 30 с с холодным кешем или 3 мин 20 с горячим кешем как на голой 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 )
• Я использую небольшой сценарий оболочки для параллельного запуска двух наборов тестов для полного запуска, и это занимает примерно 25% больше времени, чем запуск каждого из них по отдельности, что дает значительную чистую экономию за весь запуск за один раз.

Надеюсь, это кому-то поможет. Итог: откат к jest v22 был самым большим достижением. FWIW все мои коллеги испытывали проблемы, и мы запускаем каждую ОС с различными конфигурациями оборудования.

Спасибо @lulubo ! Почему вы предлагаете откатиться на 22, а не на 23?

Спасибо @lulubo ! Почему вы предлагаете откатиться на 22, а не на 23?

К сожалению, я забыл упомянуть эту часть. Наши тесты производительности с v23 были лишь ненамного лучше, чем v24. Извините, я не могу вспомнить точные цифры или процент, но в версии 22 мы увидели значительный прирост.

Я раскопался в репо, предоставленном @ELLIOTTCABLE в 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 Симен Бекхус [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 . Однако, если я удалю

collectCoverage из конфигурации, 24.8.0 также завершается за 9 секунд. Так
изменение в этом случае состоит в том, что мы фактически собираем покрытие из файлов
указано, что дорого ( особенно для больших файлов). у меня есть
переключение веток для использования покрытия V8 (# 8596
https://github.com/facebook/jest/pull/8596 ), что должно ускорить его
некоторые, но всегда будут дорого.

Быстрый тест:
[image: image]
https://user-images.githubusercontent.com/1404810/63378220-0a7b3900-c392-11e9-8ee4-f9642133bc1e.png

С исправлением, которое замедлило его, иначе весь код в шутку будет
идентичный:
[image: image]
https://user-images.githubusercontent.com/1404810/63378229-12d37400-c392-11e9-8034-558091524986.png

-
Вы получаете это, потому что вас упомянули.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/jest/issues/7811?email_source=notifications&email_token=AAAABSBCMXENWIL4T6734NTQFRB7XA5CNFSM4GURCVKKYY3PNVWWK3TUL52HS4DFVREXWORXG63JNVMV2
или отключить поток
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. Набор шутливых тестов в тестах не использует параметр collectCoverage .

Этот набор тестов не был бы открытым исходным кодом, не так ли? Похоже на отличный пример.

Если это не открытый исходный код, мне бы очень понравилось, если бы вы могли протестировать ветку next в этом репо (хотя она не должна сильно отличаться от 23.x). Если у вас есть время, было бы здорово, если бы вы могли разделить репозиторий jest пополам против вашего проекта - это то, что я сделал для сообщения выше.

@SimenB Я опубликовал похожие проблемы с производительностью 24.8

@SimenB благодарит за внимательное

@SimenB Я опубликовал похожие проблемы с производительностью 24.8

Да, эта тема довольно большая и громоздкая ... Спасибо за проверку!

Так вы думаете, что за плохой производительностью в основном стоит сбор покрытия? Я правильно понял?

Нет, только в этом конкретном случае - я не думаю, что покрытие является проблемой в общем случае. Однако все другие репродукции, которые я смотрел сегодня, имели регресс 8-> 7 секунд и т. Д., Поэтому я еще не смотрел на них слишком внимательно. Если разница огромна, найти виновного проще.

@SimenB Набор тестов принадлежит частному

У меня возникли трудности с использованием yarn link для jest-cli из-за проблемы несовместимости babel 6 vs 7. Поэтому вместо этого я попытался выполнить git bisect репозитория jest, выполнив 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 против @next в нашем наборе тестов. Кажется, небольшое улучшение, особенно для холодного кеша:

Jest 24.8, холодный кеш:

Наборы тестов: 3 пропущены, 112 пройдены, 112 из 115 всего
Тесты: 5 пропущено, 494 пройдено, всего 499
Снимки: 5 пройдено, всего 5
Время: 26,764 с
Прогнал все наборы тестов.
✨ Совершено в 27.88с.

Jest 24.8, теплый кеш:

Наборы тестов: 3 пропущены, 112 пройдены, 112 из 115 всего
Тесты: 5 пропущено, 494 пройдено, всего 499
Снимки: 5 пройдено, всего 5
Время: 20,792 с, ориентировочно 24 с.
Прогнал все наборы тестов.
✨ Совершено в 21.35 сек.

Jest 25.0 (@next), холодный кеш:

Наборы тестов: 3 пропущены, 112 пройдены, 112 из 115 всего
Тесты: 5 пропущено, 494 пройдено, всего 499
Снимки: 5 пройдено, всего 5
Время: 24.008с
Прогнал все наборы тестов.
✨ Совершено за 24.78 сек.

Теплый кеш Jest 25.0 (@next):

Наборы тестов: 3 пропущены, 112 пройдены, 112 из 115 всего
Тесты: 5 пропущено, 494 пройдено, всего 499
Снимки: 5 пройдено, всего 5
Время: 20,267 с, ориентировочно 22 с.
Прогнал все наборы тестов.
✨ Совершено в 20.86с.

Отлично, спасибо! Соответствует нашим результатам

Проблемы среды jest @ next , но я хотел опубликовать некоторые другие результаты.

Windows 10, проект Node v10.14.2 с машинописным текстом

Наборы тестов: всего 1492
Тесты: 9668 всего

Он внес некоторые другие изменения в конфигурацию на основе обсуждений в этой ветке. В первую очередь:

• Отключен сбор кода покрытия
• Изменен порядок moduleFileExtensions, чтобы ts и tsx в начале списка

Базовый уровень Jest 24,8, холодный кэш: 629 секунд
Базовый уровень Jest 24,8, теплый кэш: 296 секунд

Jest 24,8 с изменениями конфигурации, холодный кэш: 445 секунд
Jest 24,8 с изменениями конфигурации, теплый кэш: 209 секунд

По сравнению с jest 23.6 я пришел к следующим выводам:

• Время горячего кэша в 24,8 довольно близко к времени горячего кеша в 23,6. К сожалению, это все еще более трех минут, но для проекта нашего размера я думаю, что это нормально.
• Время холодного кеширования по-прежнему примерно на 60 секунд медленнее, чем время холодного кеширования в 23.6. Но, основываясь на результатах других, я уверен, что как только мы запустим jest @ next, мы увидим уменьшение времени холодного кеширования.

Как только я исправлю проблемы со своей средой, я тоже обновлю этот результат.

Извините за проблему node-gyp - я только что слил PR, который должен это исправить (# 8869). Надеюсь, у нас будет новый релиз с ним.

Также здорово, что вы смогли улучшить время на целую треть! Мы могли бы добавить какие-то документы, в которых описаны некоторые из вещей, которые можно сделать для улучшения производительности.

Например, сам Jest собирает покрытие только на узле 10 на CI (linux) - локально он не активируется.

Следующие измерения взяты из теплого кеша. Размер выборки для каждого - 10 прогонов.

шутливая версия | среднее с | std 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 ? Теоретически такая фиксация повлияет только на несколько проектов. Но если это также влияет на теплый кеш, это довольно странно. Может быть, что-то в этом рефакторинге испортило поиск в кеше? Исходный код, измененный в этом коммите, теперь живет здесь, если вы хотите в нем покопаться :

Кроме того, как вам кажется 25.0.0?

@ mucsi96
Конечно, я думаю, что основная проблема, с которой я столкнулся, была решена путем выполнения 'yarn && yarn add -D -W @ babel / core babel-core @ bridge --ignore-scripts', как предложено выше, после проверки и установки каждой фиксации .

Кроме того, и это может быть связано с чем-то, что я испортил в своей локальной среде, по какой-то необъяснимой причине мне пришлось изменить имя папки, в которой находилось мое клонированное репозиторий шуток, иначе преобразования сломались бы. ../jest/jest = неуспешно, ../jesty/jest = пройти

В остальном в основном следуя инструкциям 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 Содействующий документ был полезен. Я использую сверхтонкое и функцию рыбьей раковины для запуска тестов и электронную таблицу для записи измерений.

@SimenB :

Может быть, что-то в этом рефакторинге испортило поиск в кеше?

Вероятно. Я подделал несколько console.log () в ScriptTransformer моей локальной установки jest:

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, ваш

Ницца! Вы используете несколько проектов?

РЕДАКТИРОВАТЬ: Подождите, я уже спрашивал об этом ... Очень интересно. Как насчет первого выложенного мной патча (который заменяет слабую карту картой и делает конфигурацию ключом)?

Да, я вижу такое же ускорение и с этим!

Что-то отличается от нашего проекта / конфигурации по сравнению с 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 поскольку она должна быть стабильной

Все удары и быстрые с патчем, все промахи и медленные без.

Возможно, мне придется пересмотреть тесты и правильно построить шутку, вместо того, чтобы обезьяны исправлять @jest/transform в моей папке node_modules.

Но @ nol13 : В какой операционной системе вы использовали, чтобы разделить пополам и протестировать исправления? Я знаю, что Jest уже работает намного хуже в Windows, поэтому промахи кеша могут не иметь значения на этой конкретной платформе. Но это также могут быть мои неаккуратные методы.

Mac. Да, windows def медленнее, но не проверял разницу, может попробовать на следующей неделе. Удержание времени в разумных пределах на машинах с Windows без кровотечения действительно было его главной заботой.

В моем проекте использовался старый jest-dom/extend-expect , поэтому я заменил его на @testing-library/jest-dom/extend-expect и обновил jest до 24.9.0 , теперь тесты и покрытие выполняются молниеносно.

В окнах с узлом 10 и теплым кешем:

85-е без патча
56 с патчем

Это потрясающе! @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.0 с |
| 25 с пластырем | 6,5 с |

Я также могу воспроизвести попадание против промаха в кешировании. Спасибо за отличный репро @ nol13! Я приземлю патч сегодня позже

Да, это супер урезанное репо, но патч, примененный к 24.9.0, по-прежнему последовательно увеличивает его с 4,8 до 4,2 с и приводит к попаданию в кеш.

PR: # 8890

Этот случай с попаданием в кеш и его отсутствием сильно беспокоит. Есть ли ETA для вашего PR @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 к какой версии шутки

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 с помощью diff.

Однако, когда я запускаю 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 с исправлением? @SimenB

Для справки: jest @ next, загруженный 22 ноября, был очень медленным, но я перезагрузил его сейчас, и он выглядит намного быстрее (извините за неточность)

@dpinol интересно, какая версия работает? Версия в реестре npm, помеченная как 25.0.0 видимому, указывает на https://github.com/facebook/jest/commit/ff9269be05fd8316e95232198fce3463bf2f270e, который был до того, как было установлено исправление perf. Действительно, глядя на код unpkg для 25.0.0 (который вы получаете при установке jest@next ), исправление не применяется: https://unpkg.com/browse/@jest/transform @ 25.0 .0 / build / ScriptTransformer.js

@SimenB есть ли какая-либо версия jest (v25 + или исправленная v24), доступная в настоящее время в реестре, которая включает это исправление? Хотя использование чего-то вроде patch-package возможно, я бы предпочел не создавать и не разветвлять собственную версию, учитывая, что исправление уже существует в master. В противном случае, возможно, самым простым вариантом с вашей стороны было бы обновить тег 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

Холодно:

Наборы тестов: 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 сек.

Jest 24.9

Холодно:

Наборы тестов: 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