<p>есть 25 спектаклей</p>

Извините за регресс, но

извините, не могу поделиться нашей кодовой базой

означает, что мы абсолютно ничего не можем сделать. Это первое, что я слышал о снижении производительности, везде я слышал об улучшении производительности на 10-40% с 24 до 25. Вам нужно обеспечить какое-то воспроизведение, иначе нам придется закрыть эту проблему поскольку в нынешнем виде это вообще не имеет смысла.

Если вы хотите, чтобы это было рассмотрено, вам нужно потратить некоторое время на сборку репродукции или надеяться, что это сделает кто-то другой.

Хорошо, я посмотрю, смогу ли я провести наши 10 самых медленных тестов, может быть, а затем попробую запустить их в режиме 24 против 25. А пока что вы порекомендуете очистить кеш перед запуском тестов в CI? сделай это? не делай этого?

Ваша конфигурация, особенно transforms и файлы установки, вероятно, также актуальны.

что вы рекомендуете относительно очистки кеша перед запуском тестов в CI

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

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

FWIW, я также заметил, что v25 либо немного медленнее, либо находится на одном уровне с v24. Не видел улучшения на 10-40%.

Я увидел значительное ускорение по сравнению с шуткой 24, как указано здесь: https://github.com/facebook/jest/issues/7811#issuecomment -577057189

Вышеупомянутое было протестировано на osx.

Однако та же самая установка выполняется намного медленнее на нашем CI, на котором работает CentOS.

Проблема, связанная с Linux? Проблемы, связанные с вводом-выводом при записи файлов кеша? Можно ли вообще отключить генерацию кеша, чтобы это исключить?

Думаю, в нашем случае я нашел виноватого, это флаг --collectCoverage . Когда он удален как для Jest 24, так и для 25, наши тесты выполняются примерно в два раза быстрее до 25. Когда он включен, наши тесты до 25 лет почти в 4 раза медленнее, чем те же тесты до 24 лет.

Это воспроизводимо как в OSX, так и в CentOS, поэтому, вопреки моему предыдущему комментарию, проблема не связана с Linux.

Интересный! Мы обновили Стамбул до версии 3, возможно, там что-то пошло не так. Мы добавили поддержку покрытия кода v8, так что, возможно, я также испортил рефакторинг при этом.

Да! Это также согласуется с тем, что я вижу. Мы работаем с покрытием в CI, где оно в 2 раза медленнее. И когда я бегаю локально без covg, это довольно быстро. @SimenB есть ли какой-либо вариант конфигурации для использования старого Стамбула? :)

Повторяя то, что сказал @csvan, было бы неплохо отключить генерацию кеша в CI, если это на самом деле виноват, поскольку мы все равно удаляем его перед сборкой

Я не могу воспроизвести это - репозитории, которые я тестировал, имеют примерно одинаковую производительность с --coverage между v24 и v25. Сможет ли кто-нибудь собрать репозиторий с jest 24 и jest 25, где переключение между ними показывает разницу?

только что запустил нашу сборку CI с отключенным покрытием, я думаю, что @csvan что-то

наш exinfo из агента сборки:

00:03:31.992   System:
00:03:31.992     OS: Linux 3.10 CentOS Linux 7 (Core)
00:03:31.992     CPU: (8) x64 Intel Core Processor (Skylake, IBRS)
00:03:31.992   Binaries:
00:03:31.992     Node: 10.16.0 - ~/workspace/grocery-electrode/tools/nix_64/nodejs-10.16.0/bin/node
00:03:31.992     npm: 6.9.0 - ~/workspace/grocery-electrode/tools/nix_64/npm-6.9.0/node_modules/.bin/npm
00:03:31.993   npmPackages:
00:03:31.993     jest: 25.1.0 => 25.1.0 

Мы наблюдаем аналогичную проблему. Обновление Jest 25 замедлило наши тесты при использовании покрытия (166 с Jest 24 против 381 с Jest 25). Jest 25 отображает многие из этих ошибок при выполнении проверок:

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

<--- Last few GCs --->

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


<--- JS stacktrace --->

Переход на Jest 24 устраняет эти ошибки.

Я также заметил, что Jest 25 по-другому обрабатывает collectCoverageFrom поскольку, похоже, он собирает покрытие из файлов, которые мы явно отключили в этой конфигурации. Изменилась ли там поддержка синтаксиса glob?

Есть ли вообще следы JS? Было бы интересно посмотреть, где он умер.

Я также заметил, что Jest 25 по-другому обрабатывает collectCoverageFrom, поскольку, похоже, он собирает покрытие из файлов, которые мы явно отключили в этой конфигурации. Изменилась ли там поддержка синтаксиса glob?

Мы перешли на Micromatch 4, возможно, это что-то изменило. Впрочем, никаких намеренных изменений в него нет. Не могли бы вы открыть отдельный выпуск репродукции?

Есть ли вообще следы JS?

Это было напечатано:

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

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

РЕДАКТИРОВАТЬ : На самом деле я вижу ошибки кучи даже при отключенном покрытии.

Мы перешли на Micromatch 4, возможно, это что-то изменило. Впрочем, никаких намеренных изменений в него нет. Не могли бы вы открыть отдельный выпуск репродукции?

Сделаю.

Снова вмешиваюсь. Охват определенно медленнее и кажется ложным. Вот тайминги для OSX.

46.69
41.77
45.06

v24 coverage
78.60
75.79
80.38

v25
45.93
52.49
53.36

v25 circus
61.27
52.08

v25 coverage
310.98
227.15
153.81

Сроки для CI (travis).

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

@milesj что такое цирк v25?

Это шутка о новом раннере, который должен быть быстрее, но это не то, что я видел. https://www.npmjs.com/package/jest-circus

@EvHaus Traces from JSDOM интересен (конечно, тоже может быть полностью случайным). Не могли бы вы попробовать установить jest-environment-jsdom@24 и использовать это? Мы обновились с 11 до 15, так что что-то там могло измениться. Кажется, что это не так, но кто знает

@SimenB Откат всего лишь jest-environment-jsdom до <24.0.0 в моем package.json определенно оказал влияние. Ошибки heap out of memory исчезли, и Jest, кажется, завершает свои запуски без каких-либо проблем.

Интересный! Если бы у вас было время, было бы замечательно, если бы вы могли протестировать

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

Или просто вставьте ссылку в jsdom и разделите пополам. Я сделаю это завтра, но у меня пока нет хорошего воспроизведения

Для следующих тестов у меня не включено покрытие.

• С [email protected]
  
  
  
  • 143с на запуск тестов
  
  
  • Без вопросов
  
  
• С [email protected]
  
  
  
  • 154 с на запуск тестов
  
  
  • Без вопросов
  
  
• С [email protected]
  
  
  
  • 228с на запуск тестов
  
  
  • 🚨Много JavaScript heap out of memory ошибок
  
  

Следы стека

Вот некоторые из трассировок стека из запуска jest-environment-jsdom-fourteen :

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

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

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

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

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

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

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

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

Надеюсь это поможет

Я не знаю, поможет ли это, но у моей организации было значительное замедление с Jest 24 до Jest 25 (с 18 до 28 минут), которое исчезло после отключения сбора информации (до 10 минут).

@rosasynstylae из любопытства, много ли в вашем коде тестов снимков?

@benmonro Есть , да.

Наши тоже! @SimenB, как вы думаете, причиной этого могло быть множество снимков в репо?

У нас проблемы с производительностью из-за отсутствия снимков. Тем не менее, мы собираем покрытие. Значительное замедление с 24 до 25. 2 разных проекта. Он варьируется, но замедление является значительным и постоянным.

Я могу запускать тесты снова и снова без изменений, и тесты в среднем в 10 раз медленнее, чем они были с 24.

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

При необходимости я могу предоставить дополнительную информацию. Я хотел бы обязательно упомянуть наши 2 проекта без тестов моментальных снимков.

Судя по всем приведенным здесь комментариям, это определенно звучит так, будто проблема в покрытии и, вероятно, в регрессе в Стамбуле?

Судя по всем приведенным здесь комментариям, это определенно звучит так, будто проблема в покрытии и, вероятно, в регрессе в Стамбуле?

Я бы не стал так быстро указывать пальцем на Стамбул. В моем случае, даже с отключенным покрытием, я наблюдаю значительные проблемы с производительностью и стабильностью в Jest 25. См. Https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Возможно, есть две отдельные проблемы:

1) Проблемы с jest-environment-jsdom-четырнадцать и
2) Проблемы с покрытием стамбула

Я понизил рейтинг micromatch до ^3.0.0 и увидел значительное ускорение с использованием --coverage , более или менее возвращающееся к производительности, которую мы видели в Jest 24. Может ли кто-нибудь воспроизвести?

ОБНОВЛЕНИЕ: однако теперь работа без --coverage также вернулась к уровням производительности Jest 24 - вдвое медленнее: - /

@EvHaus спасибо за проверку, очень интересно! К сожалению, я все еще не могу воспроизвести это. Так что воспроизведение все равно будет отличным, так что я могу попытаться отладить это.

Я понизил рейтинг micromatch до ^3.0.0 и увидел значительное ускорение с использованием --coverage , более или менее возвращающееся к производительности, которую мы видели в Jest 24. Может ли кто-нибудь воспроизвести?

ОБНОВЛЕНИЕ: однако теперь работа без --coverage также вернулась к уровням производительности Jest 24 - вдвое медленнее: - /

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

Вся эта штука с производительностью микроматч становится немного абсурдной: с покрытием v3 быстрее, чем v4, без v4 быстрее, чем v3? 😅

@SimenB Ага ,

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

к нашему package.json сэкономил целых 6 минут при использовании --coverage , что примерно вернуло результат к тому, что мы видели в Jest 24.

Насколько я понимаю, в Стамбуле ничего не зависит от микроматча

Нашел этот комментарий в другом потоке, который может быть связан с этим:

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

Только что подтвердил, что в Стамбуле ничего не тянет micromatch (они используют minimatch в плагине babel).

Это может быть что-то из-за того, что исключения не работают должным образом, определенно. Мы используем его, чтобы проверить, что мы должны использовать: https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. Не могли бы вы войти в систему и посмотреть, вернем ли мы true где-нибудь с micromatch@4 чего мы не делаем для micromatch@3 ?

Определенно кажется, что это две отдельные проблемы, одна о jsdom, а другая о покрытии.

Я могу подтвердить, что она вернулась к нормальной скорости для нас в CI, когда мы также разрешим micromatch @ 3 .

Jest + typescript + код реакции здесь. Увидев эту проблему и используя npm-force-resolution для принудительного выполнения микроматч ^ 3.0.0, казалось, что это сумасшедшее замедление устранило.

Есть ли в вашей конфигурации пользовательские шаблоны тестовых файлов, шаблоны покрытия PR?

@EvHaus Меня очень интересует, видите ли вы разницу при понижении версии Micromatch, поскольку вы видели большую разницу с версиями jsdom

Если вы это имеете в виду, то да.

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

у нас тоже есть это, и наш выглядит очень похожим по длине / значениям

@ Ancient123 да, именно так. Кажется, связано с регрессией Micromatch для инвертированных паттернов. Спасибо!

Кажется, связано с регрессией Micromatch для инвертированных паттернов. Спасибо!

Отметил, я изучу это как можно скорее.

Вся эта штука с микроматчем становится немного абсурдной.

Извините за снижение производительности. Генерация регулярных выражений для подстановки символов намного сложнее, чем кажется. Особенно, когда ему нужно справиться с отрицанием и быть кроссплатформенным. Я сейчас занимаюсь этим.

@jonschlinkert, это вовсе не означало

да! что сказал @SimenB . ничего кроме ❤️

@EvHaus Меня очень интересует, видите ли вы разницу при понижении версии Micromatch, поскольку вы видели большую разницу с версиями jsdom

В моем package.json я установил:

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

Повторно запустил npm install , а затем вручную удалил node_modules/jest/micromatch (который был в версии 4). Затем повторно прогнал мои тесты.

К сожалению, я все еще вижу много ошибок типа «Не хватает памяти в куче JavaScript».

Правильно ли я переключаюсь на более раннюю версию?

resolutions требует yarn , npm еще не реализовал (это в дорожной карте для версии 7: https://blog.npmjs.org/post/186983646370/npm- cli-roadmap-лето-2019)

@EvHaus, пока не https://www.npmjs.com/package/npm-force-resolutions

Извините за задержку. Используется npm-force-resolutions (что делает правильные вещи), чтобы заблокировать micromatch на v3. К сожалению, мои ошибки в куче не исчезли.

Так что для меня виноват [email protected] , как упоминалось здесь: https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Преобразование jsdom в thirteen - вот что это исправляет.

Есть ли у кого-нибудь, кто испытал снижение производительности в 25 странах , проблемы, которые не jsdom @ 13 или micromatch @ 3? Утечка памяти в JSDOM исправляется (https://github.com/jsdom/jsdom/pull/2840 и различные проблемы / PR, связанные с ним), и сообщалось о регрессии в микроматче, и над ней работают: https: // github.com/micromatch/micromatch/issues/179.

Выпущена фиксированная версия JSDOM, вы можете использовать ее, установив jest-environment-jsdom-sixteen . @EvHaus не могли бы вы убедиться, что он

@SimenB, моя проблема, вероятно, не связана, но я попробовал jest-environment-jsdom-sixteen vs по умолчанию и увидел увеличение времени выполнения того же набора тестов на 20 с при повторных запусках.

за использование версии 15 (которая по умолчанию поставляется с шуткой) и никаких других изменений? Не могли бы вы протестировать и с 16.1.0 (хотя это приводит к утечке памяти, поэтому может быть сложнее проверить). JSDOM только что появился с поддержкой настраиваемых элементов, _не_ может быть там регресс? Точно сказать не могу

Выпущена фиксированная версия JSDOM, вы можете использовать ее, установив jest-environment-jsdom-sixteen. @EvHaus не могли бы вы убедиться, что он

К сожалению, все еще возникают ошибки кучи с jest-environment-jsdom-sixteen . Последняя стабильная рабочая версия JSDom для меня - jest-environment-jsdom-thirteen .

Выпущена фиксированная версия JSDOM, вы можете использовать ее, установив jest-environment-jsdom-sixteen . @EvHaus не могли бы вы убедиться, что он

Среда работает с нашей кодовой базой, но мы все еще наблюдаем почти 100% регресс во время выполнения. Как ни странно, jest-environment-jsdom-sixteen похоже, улучшает производительность времени выполнения на 10% только при использовании 25.1 vs 24.9

Привет @SimenB!

Я привел воспроизводимый пример здесь https://github.com/olebedev/jest-perf-issue. Взгляни, пожалуйста. Ниже приведен результат для сравнения. / cc @joscha

Результаты

Тесты выполнялись на MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz .

| шутливая версия | филиал | время |
|: -------------- |: ------: | ----------: |
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

В нашем случае, когда jest v25.1 был на ~ 50% медленнее по сравнению с v24.9, теперь последний jest v25.2.0 еще на 20% медленнее по сравнению с v25.1 🙈

@olebedev Ого , больно

Я получаю тебе похожие числа. Если это основано на реальном проекте, я рекомендую использовать покрытие v8. На моей машине в вашем воспроизведении время работы составляет от 600 до 35 секунд. Причина огромного различия, вероятно, в том, что мы не пытаемся инструментировать непокрытые файлы с покрытием v8 (мы просто говорим, что каждый байт открыт, что работает с v8).

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

Не уверен, почему это так медленно ... Я постараюсь найти время, чтобы изучить это (хотя и не скоро). По крайней мере, на v25 он не должен быть медленнее, чем на v24.

Правильно ли я понимаю документацию, что мы можем использовать покрытие v8 вместе
со средой ...-sixteen ?

Ваше здоровье,
J

В среду, 8 апреля 2020 года, 22:33 Симен Бекхус, [email protected] написал:

@olebedev https://github.com/olebedev Ого , больно

Я получаю тебе похожие числа. Если это основано на реальном проекте, я
рекомендую использовать покрытие v8. Время работы у меня составляет от 600 до 35 секунд.
машина в вашем репродукции. Причина огромной разницы, вероятно, в том, что
мы не пытаемся инструментировать непокрытые файлы с покрытием v8.

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

Не знаю, почему так медленно ... Я постараюсь найти время, чтобы разобраться в этом.
По крайней мере, на v25 он не должен быть медленнее, чем на v24.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

Да, либо jest-environment-jsdom-sixteen , либо пакетный jest-environment-node . Также обратите внимание, что он поддерживается только на узле 10+, но не на узле 8.

(Я когда-либо тестировал это только с помощью Node env, но если он не работает с jsdom env, это ошибка - пожалуйста, откройте отдельную проблему 🙂)

jest-environment-jsdom-sixteen + v8 в качестве поставщика покрытия был хуже примерно на 20% для нас на jest 25.3.0, node 12.16. Мы также пытаемся отладить, почему производительность нашего теста ухудшилась примерно на 80% при переходе от шутки 24 к 25.

@joual вы пробовали обходной путь микроматч (переход на 3.x)?

Имея аналогичный опыт здесь, время тестирования (без покрытия) удваивается на v25 с 35-40 секунд до 80-90, а иногда и больше. Пробовал блокировать микроматч на v3, заметной разницы нет. Fwiw, у нас есть около 3k тестов, из которых 58 являются тестами моментальных снимков.
Попытка перейти на более раннюю версию jsdom, но это, похоже, приводит к большим сбоям в тестировании из-за недавних функций, которые мы использовали. Я посмотрю, смогу ли я как-нибудь обойти это, и доложу.

@SimenB Работа по сбору покрытия на более красивом проекте тоже очень медленная, вы можете это проверить? https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest собирает покрытие, другая работа - нет.

Имея аналогичный опыт здесь, время тестирования (без покрытия) удваивается на v25 с 35-40 секунд до 80-90, а иногда и больше. Пробовал блокировать микроматч на v3, заметной разницы нет. Fwiw, у нас есть около 3k тестов, из которых 58 являются тестами моментальных снимков.
Попытка перейти на более раннюю версию jsdom, но это, похоже, приводит к большим сбоям в тестировании из-за недавних функций, которые мы использовали. Я посмотрю, смогу ли я как-нибудь обойти это, и доложу.

Сегодня экспериментировал с разными версиями jsdom на jest @ 24 (по умолчанию v11). До v14 вроде бы все работает нормально, но с v15 тестовые прогоны постоянно занимают на 50-60% больше времени. Та же история в версии 16. Посмотрим, смогу ли я получить аналогичную производительность на jest @ 25 , понизив jsdom до v14.

[email protected] имеет некоторые исправления памяти, @EvHaus не могли бы вы попробовать? Собственный --detect-leaks Jest обнаруживает утечки в предыдущих версиях, но не в версии 16.2.2.

Я также внес некоторые другие улучшения, если у вас много символических ссылок (что очень медленно для Windows), поэтому, если бы люди могли попробовать [email protected], это было бы прекрасно 🙂

@SimenB Какой самый простой способ это проверить? Если я добавляю [email protected] напрямую как devDependency Jest игнорирует это и использует все, что связано с jest-environment-jsdom которое сегодня составляет 15.2.1.

Как я могу обмануть npm чтобы убедиться, что он использует нужную мне версию jsdom?

Установите jest-environment-jsdom-sixteen и используйте его https://jestjs.io/docs/en/configuration#testenvironment -string

Альфа-версия опубликована, так что вы можете попробовать jest@next - он поставляется с jsdom 16 из коробки

@SimenB Извините, не очень повезло с [email protected] и его [email protected] . По-прежнему возникают многие из этих ошибок:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

И в конце концов бегун умирает.

Мои детали:

> npx envinfo --preset jest

  System:
    OS: macOS 10.15.4
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
  Binaries:
    Node: 10.17.0 - ~/.nvm/versions/node/v10.17.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v10.17.0/bin/npm
  npmPackages:
    jest: ^26.0.0-alpha.0 => 26.0.0-alpha.0 

Вот некоторые из полных стеков, возвращенных из них:

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

<--- Last few GCs --->

[50818:0x102804000]   189738 ms: Mark-sweep 1288.8 (1450.6) -> 1280.2 (1454.1) MB, 890.1 / 0.1 ms  (average mu = 0.181, current mu = 0.061) allocation failure scavenge might not succeed
[50818:0x102804000]   190673 ms: Mark-sweep 1292.8 (1454.1) -> 1282.9 (1457.6) MB, 856.2 / 0.2 ms  (average mu = 0.136, current mu = 0.084) allocation failure scavenge might not succeed


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x3f82f50dbe3d]
Security context: 0x274d67c9e6e9 <JSObject>
    1: createImpl [0x274d6d9ba1b9] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/generated/HTMLInputElement.js:~47] [pc=0x3f82f5c630de](this=0x274d51911261 <Object map = 0x274dd51fe489>,globalObject=0x274d89d38609 <Window map = 0x274d2fe6c211>,constructorArgs=0x274d832134b1 <JSArray[0]>,privateData=0x274d832134d1 <Object map = 0x274d69...

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

<--- Last few GCs --->

[51263:0x102804000]    34292 ms: Mark-sweep 1332.4 (1452.5) -> 1320.5 (1453.5) MB, 902.6 / 0.0 ms  (average mu = 0.149, current mu = 0.104) allocation failure scavenge might not succeed
[51263:0x102804000]    35480 ms: Mark-sweep 1332.6 (1453.5) -> 1323.6 (1457.5) MB, 1049.3 / 0.0 ms  (average mu = 0.131, current mu = 0.116) allocation failure scavenge might not succeed


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x2cea552dbe3d]
Security context: 0x1a4cb371e6e9 <JSObject>
    1: next [0x1a4ca627dcd1] [/Users/evhaus/Git/zenhub/client/node_modules/symbol-tree/lib/TreeIterator.js:~16] [pc=0x2cea55937c04](this=0x1a4c807c75b1 <TreeIterator map = 0x1a4c38b8a9c9>)
    2: shadowIncludingInclusiveDescendantsIterator(aka shadowIncludingInclusiveDescendantsIterator) [0x1a4ca627a641] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/li...

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

<--- Last few GCs --->

[51519:0x102804000]    28074 ms: Mark-sweep 1324.5 (1445.0) -> 1315.7 (1449.0) MB, 760.4 / 0.0 ms  (average mu = 0.182, current mu = 0.080) allocation failure scavenge might not succeed
[51519:0x102804000]    28906 ms: Mark-sweep 1328.5 (1449.0) -> 1317.7 (1452.0) MB, 770.4 / 0.0 ms  (average mu = 0.129, current mu = 0.074) allocation failure scavenge might not succeed


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x3e0d8aedbe3d]
Security context: 0x3611d141e6e9 <JSObject>
    1: queueMutationRecord(aka queueMutationRecord) [0x361185f32321] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/helpers/mutation-observers.js:~33] [pc=0x3e0d8b35eedc](this=0x361116e826f1 <undefined>,type=0x3611aa0a3681 <String[9]: childList>,target=0x36110b275a91 <EventTargetImpl map = 0x3611a254a2f1>,name=0x361116e822b1 <null>,name...

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

[51526:0x102804000]    33125 ms: Mark-sweep 1318.6 (1425.0) -> 1317.7 (1424.0) MB, 874.8 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure scavenge might not succeed
[51526:0x102804000]    33136 ms: Scavenge 1318.5 (1424.0) -> 1318.0 (1424.5) MB, 3.8 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure 
[51526:0x102804000]    33148 ms: Scavenge 1318.7 (1424.5) -> 1318.2 (1425.0) MB, 4.2 / 0.0 ms  (average mu = 0.126, current mu = 0.038) allocation failure 


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x8d8aedbe3d]
    1: StubFrame [pc: 0x8d8ae8d40b]
    2: ConstructFrame [pc: 0x8d8ae8cfa3]
Security context: 0x3324ecd9e6e9 <JSObject>
    3: new NodeImpl(aka NodeImpl) [0x3324c2083e11] [/Users/evhaus/Git/zenhub/client/node_modules/jsdom/lib/jsdom/living/nodes/Node-impl.js:~125] [pc=0x8d8b357fd4](this=0x332437582801 <the_hole>,globalObject=0x3324b10f98e9 <Window map = 0x3324649cf0a1>,args=0x3324b1841471 <JSArray[0]>,...

Очень плохо 😞 Это с покрытием или без?

Это было без покрытия. Должен был уточнить.

Как вы думаете, может ли это повлиять на то, что я использую довольно старую версию Node (v10)?

Вы можете попробовать использовать более новые версии, иначе это будет интересным моментом. Еще можно попробовать сделать дамп кучи прямо перед тем, как он умрет. Что в куче?

Интересно, что никто не упомянул, что micromatch @ 4 больше не кэширует регулярные выражения (см. Https://github.com/micromatch/micromatch/pull/151, а https://github.com/facebook/jest/pull/10131 вводит отсутствующие кеширование на стороне шутки.

Для меня переход на micromatch @ 3 и обновление до jest-environment-jsdom-sixteen сэкономили 50% времени.
Но с jest 26 и встроенным jsdom я все еще получаю ошибку утечки при запуске jest с --detectLeaks в моем случае. Пробовал свежее репо, и все работает хорошо.

https://github.com/facebook/jest/pull/10131 объединен !! <3

Выпущено в 26.1.0, очень интересно услышать, поможет ли это людям

@SimenB большое спасибо за релиз! к сожалению, с нашей стороны, мы все еще сталкиваемся с огромной разницей:

Текущий:

os: osx
node: 12.6.1
jest: 24.9
-----------------
174 test suites
823 tests
322 snapshots
-----------------
done in 23.569s

на каждой версии выше 24.9

os: osx
node: 12.6.1
jest: 26.1.0
-----------------
174 test suites
823 tests
322 snapshots
-----------------
done in 133.763s

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

@SimenB

За prettier проекта, по- прежнему медленно , чем v24 при сборе покрытия.

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

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

@SimenB Я сделал git bisect чтобы выяснить, где возникла регрессия производительности между 24,9 и 25,1. Я использовал более красивые тесты, потому что они проходят без изменений от 24,9 до 26,1.

Я сравнил накопленное время выполнения трех запусков подмножества js (чтобы сберечь время) с отключенным кешем. В частности, я использовал команду ( yarn run jest --no-cache tests/js/ ) с узлом 10.19. поскольку узел 10 был рекомендованной версией для 24.9.

Результаты:

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

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

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

Поскольку существует резервный вариант, если compileFunction не определено, я удалил ветку compileFunction из ad5377333daf6716af3465bba39f86b7db485e2b, которая восстановила производительность.

Если посмотреть на 26.1, то код немного изменился, но compileFunction и запасной вариант все еще существуют. Так:

26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 242.99s <- with compileFunction
26.1.0-dev 817d8b6aca845dd4fcfd7f8316293e69f3a116c5 151.61s <- without compileFunction

то есть удаление ветки compileFunction ( патч ) возвращает 26.1 к среде выполнения 24.9. Я уверен, что это не выход, но, по крайней мере, нам есть над чем работать.

В качестве еще одной точки данных, наш набор шуток в настоящее время занимает около 2767 секунд с [email protected], а в нашем обновлении MR - около 3497 секунд, что примерно на 27%.

Спасибо за отличную работу, команда шутников , я надеюсь, что детективные навыки

@wurstbonbon, спасибо, что compileFunction медленнее ... Это должно означать, что вы можете просто использовать настраиваемую тестовую среду вместо применения патча.

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(и то же самое для jsdom env). Можешь подтвердить?

Хотя это узкое место звучит странно - сам Node переключился на его использование 18 месяцев назад: https://github.com/nodejs/node/pull/21573. Так что, вероятно, мы делаем что-то странное на нашей стороне. Связанный https://github.com/nodejs/node/issues/26229 очень интересен - может быть, нам нужно сделать еще кеширование на нашей стороне?

@SimenB Я просто попробовал что-то похожее на этот пользовательский env, и похоже, что это было немного лучше (но все же медленнее, чем jest 24).

Однако мне пришлось сделать MyNodeEnv.prototype.getVmContext = null; , потому что я тестирую с помощью jest 26, и теперь похоже, что он проверяет if (typeof this._environment.getVmContext === 'function') { . Не уверен, что это может вызвать другие проблемы.

Вот результаты, которые я вижу после нескольких прогонов:

Jest 26 с testEnvironment: "node" => ~ 280 сек.
Jest 26 с пользовательской тестовой средой => ~ 210 с
Jest 24 => ~ 160 с

Дайте мне знать, если я могу помочь с какой-либо другой информацией или чем-то еще!

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

Я также пробовал это на нашей кодовой базе, где разница составляет ~ 270 с против ~ 200, так что только около 25%, а не 40%. К сожалению, я не могу запустить наши тесты с помощью jest 24, потому что мы полагаемся на насмешку с новыми современными таймерами.

Я пропустил delete в моем примере выше, извините за это.

Интересно, достаточно ли просто кэшировать скомпилированные функции вручную - не могли бы вы попробовать применить этот патч? (сюда включены как транспилированный JS, так и исходный код TS)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я думал, это может помочь.

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

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

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

Это немного улучшает производительность, но Script по-прежнему намного быстрее.

Пробовал рекомендацию от @SimenB : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs?commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

Хотя он немного улучшил производительность, он все же значительно медленнее, чем на jest 24.x:

• Jest 24.x: общее время выполнения наших шутливых тестов 2580 секунд
• Jest 26.x: общее время выполнения наших шутливых тестов 3166 секунд

@leipert Вы случайно не пробовали понизить среду jsdom до 14?

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" в вашем конфиге jest. Кажется, что это по-прежнему является причиной увеличения продолжительности для нас (добавляет 40-50%), но начинает выглядеть так, как будто в игре есть несколько регрессов.

@pleunv С jest 24.x мы находимся на jsdom 16 с jest-environment-jsdom-sixteen , нам пришлось выполнить обновление из-за некоторых проблем с тестированием веб-компонентов. Итак, единственное изменение, которое мы делаем: jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom , поэтому версия jsdom даже не меняется.

Открыл https://github.com/nodejs/node/issues/35375 апстрим о проблеме, обнаруженной @wurstbonbon

@SimenB знаете ли вы какие-нибудь жизнеспособные альтернативы микроматчу? Это репо молчало уже более полугода, и основные проблемы, влияющие на Jest, такие как https://github.com/micromatch/micromatch/issues/179 , все еще открыты.

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

@SimenB Что делает микроматч лучше всех альтернатив?

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

@leipert @wurstbonbon или кто-нибудь еще, можете ли вы попробовать этот патч в своем node_modules/jest-runtime/build/index.js ?

diff --git i/packages/jest-runtime/build/index.js w/packages/jest-runtime/build/index.js
index 851d8e12cd..7235082546 100644
--- i/packages/jest-runtime/build/index.js
+++ w/packages/jest-runtime/build/index.js
@@ -1170,35 +1170,24 @@ class Runtime {
       value: this._createRequireImplementation(localModule, options)
     });
     const transformedCode = this.transformFile(filename, options);
-    let compiledFunction = null; // Use this if available instead of deprecated `JestEnvironment.runScript`
+    let compiledFunction = null;
+    const script = this.createScriptFromCode(transformedCode, filename);
+    let runScript = null; // Use this if available instead of deprecated `JestEnvironment.runScript`

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

       if (vmContext) {
-        try {
-          compiledFunction = (0, _vm().compileFunction)(
-            transformedCode,
-            this.constructInjectedModuleParameters(),
-            {
-              filename,
-              parsingContext: vmContext
-            }
-          );
-        } catch (e) {
-          throw (0, _transform().handlePotentialSyntaxError)(e);
-        }
+        runScript = script.runInContext(vmContext, {
+          filename
+        });
       }
     } else {
-      const script = this.createScriptFromCode(transformedCode, filename);
-
-      const runScript = this._environment.runScript(script);
+      runScript = this._environment.runScript(script);
+    }

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

     if (compiledFunction === null) {

Я протестировал патч, чтобы использовать Script в наших тестовых наборах, и вот результат, к которому я пришел
Время в min:sec

Имя | Люкс 1 | Люкс 2 | Люкс 3 | Люкс 4
- | - | - | - | -
шутка 24 | 3:25 | 3:30 | 3:29 | 0:53
шутка 26 пропатчен | 3:32 | 4:36 | 3:48 | 0:53
шутка 26 не исправлена ​​| 5:10 | 6:12 | 5:11 | 1:07
26 пропатченных против 24 | 4% | 31% | 9% | 1%
26 непропатченных и 24 | 52% | 76% | 49% | 27%
26 исправленных vs непропатченных | 46% | 35% | 36% | 25%

все еще интересно, что v26 все еще не улучшает v24 ...

Спасибо, @Cellule! Для меня этого достаточно - я сделаю пиар, когда у меня будет время

Потрясающий материал! Остается только проблема с Micromatch, надеюсь, это репо снова будет активно поддерживаться.

Кстати, я полагаю, что в JSDOM также есть регрессия производительности. Как я делал такие тесты на большом веб-проекте. Упомянутые выше патчи не применяются.
И это выглядело так.

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

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

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

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

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

https://github.com/facebook/jest/releases/tag/v26.5.0 обсуждает изменение vm.Script здесь

(Изменить: обновлено после дополнительных прогонов)

Предварительные результаты на том же наборе тестов:

Шутка 26,5
Холодно: 59.992
Горячий: 43.976

Jest 26.4:
Холодно: 90,213
Горячий: 47.408

Значительное ускорение при холодном прогоне <3

И вот результаты моего набора тестов:

Шутка 26,5
Холодная: 149 с

Шутка 26.4
Холодная: 226 с

Отличные новости 🙂 Я думаю, мы вернулись только к регрессии микроматч, тогда

Если вы, ребята, используете npm-force-resolutions для принудительной установки микроматча 3. Это может не работать в [email protected]

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

Ошибка при запуске теста:

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

@SimenB Большое спасибо за обновление. Это экономит нам 20% времени работы Travis после обновления до [email protected]

Наши результаты:

Это v26.5

• 323,98 с
• 321,24 с

Это v24.9

• 262,17 с
• 275.96 с

Спасибо @SimenB! Это потрясающе. Наши результаты для наших ~ 22000 тестов в ~ 2000 наборах:

• Jest 24.x: 2864 с
• Jest 26.5.2: 2967 с

что примерно на 3% медленнее и, следовательно, в пределах погрешности, по сравнению с замедлением на ~ 27%, которое мы видели раньше. Спасибо, теперь нам просто нужно слить: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Просто хотел отметить, что все проблемы с "нехваткой

ОБНОВЛЕНИЕ : Забудь. Я снова начал получать ошибки OOM. Я думаю, это на грани того, с чем может справиться мой ноутбук, и первые несколько запусков были хорошими, но теперь он снова умирает. Придется еще придерживаться 24.xx :(

Если кому-то интересно, я создал DOM, который имеет очень хорошую производительность по сравнению с JSDOM. Он поддерживает Jest.

| Операция | JSDOM | Счастливый ДОМ |
| ------------------------------------ | ------- | --------- |
| Импорт / Требовать | 333 мс | 45 мс |
| Разобрать HTML | 256 мс | 26 мс |
| Сериализовать HTML | 65 мс | 8 мс |
| Визуализировать настраиваемый элемент | 214 мс | 19 мс |
| querySelectorAll ('tagname') | 4,9 мс | 0,7 мс |
| querySelectorAll ('. класс') | 6,4 мс | 3,7 мс |
| querySelectorAll ('[атрибут]') | 4.0 мс | 1,7 мс |
| querySelectorAll ('[class ~ = "name"]') | 5,5 мс | 2,9 мс |
| querySelectorAll (': nth-child (2n + 1)') | 10,4 мс | 3,8 мс |

Ссылка на проект:
https://github.com/capricorn86/happy-dom/

@ capricorn86 Выглядит неплохо. Это соответствует спецификации?

@ capricorn86 Выглядит неплохо. Это соответствует спецификации?

Спасибо, @milesj!

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

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

FWIW, я только что попытался поднять наш проект с react-scripts@3 с Jest 24.9 до @react-scripts@4 с Jest 26.6.

Наш тестовый набор серверного API раньше выполнялся примерно за 180–190 секунд. После перехода на Jest 26.6 это постоянно занимало около 220 секунд. Я даже попытался принудительно разрешить minimatch до 4.0.2 . Переключение тестовой программы на jest-circus казалось, сбило с толку пару секунд, но в целом 26.6 кажется заметно медленнее.

react-scripts@4 jest-circus по умолчанию использует micromatch , а не minimatch . Кажется, мы прервали откат micromatch через # 10131, однако не так легко проверить, является ли это причиной регресса.

@SimenB : у нас есть странная установка для миграции - это устаревшее приложение MEAN / AngularJS, которое я преобразовал для сборки с использованием CRA . Конфигурация теста - наша собственная, в отличие от встроенной конфигурации CRA Jest - мы просто пользуемся тем фактом, что CRA поставляется с Jest в качестве зависимости.

У меня нет своей рабочей коробки перед банкоматом, поэтому теперь я не могу вспомнить, имел ли я в виду micromatch или действительно сосредоточился на неправильном названии пакета :) Мне нужно посмотреть на следующей неделе.

Я только что заметил, что v26 в iTerm работает намного медленнее, чем в терминале по умолчанию macOS. На наборе из 6500 тестов стабильно получаю следующие результаты:

• v24, Терминал: ~ 90 с
• v24, iTerm2: ~ 90 с
• v26, Терминал: ~ 110 с
• v26, iTerm2: ~ 150 с

Это немного поразило меня после нескольких месяцев попыток разобраться с замедлением. Есть ли шанс, что кто-нибудь еще с проблемами производительности на Mac может попробовать это? Имейте в виду, это с jsdom @ 14 на v26.

@pleunv Я считаю, что это может быть связано: https://github.com/facebook/jest/pull/9294. Я заметил, что гиперссылки замедляют работу iTerm2 на моем компьютере, делая его нестабильным. Но не исследовал общую скорость выполнения и не нашел другого человека, у которого были проблемы с этим.

Эврика. Поиск по запросу "iTerm" привел меня к этому пиару . Я раньше замечал эти подчеркивания и не понимал, что это гиперссылки. Увидев этот PR, я отключил гиперссылки в iTerm, что снизило время выполнения до 130 секунд. После применения кода из PR и удаления гиперссылок я возвращаюсь к 120s. Рассудок немного восстановлен.

Есть ли шанс, что пиар вернется?

edit: @thymikee опередил меня 😄

@pleunv Я постараюсь найти время на этой неделе, чтобы вернуть его. Хотя реальная проблема заключалась бы в том, чтобы исправить это для iTerm, поскольку другие терминалы, например, в Linux, не имеют проблем с гиперссылками. Не могли бы вы подать вопрос в проект iTerm?

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

Это может быть очень важно для больших тиражей. ❤️

//редактировать
Забавно, что раньше не имело значения, будет ли это окончательно или окончательно. После смены итерм у меня стал быстрее.

@pleunv Я постараюсь найти время на этой неделе, чтобы вернуть его. Хотя реальная проблема заключалась бы в том, чтобы исправить это для iTerm, поскольку другие терминалы, например, в Linux, не имеют проблем с гиперссылками. Не могли бы вы подать вопрос в проект iTerm?

Я создал здесь проблему (они на GitLab). Если у кого-то есть дополнительные детали или репро-проект, не стесняйтесь добавлять.

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

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