<p>há uma performance de 25</p>

Desculpe pela regressão, mas

desculpe, não posso compartilhar nossa base de código

significa que não podemos fazer absolutamente nada. Esta é a primeira vez que ouço falar de regressão de desempenho; em todos os outros lugares, ouvi de 10-40% de _melhoria_ de desempenho indo de 24 para 25. Você precisa fornecer algum tipo de reprodução, caso contrário, teremos que fechar este problema já que não é acionável como está.

Se você quiser ver este endereço, precisará gastar algum tempo montando uma caixa de reprodução, ou esperar que outra pessoa o faça.

OK, verei se consigo puxar nossos 10 testes mais lentos, talvez, e tente executá-los em 24 contra 25. Enquanto isso, o que você recomenda com relação à limpeza do cache antes de executar testes em CI? faça? não faz isso?

Sua configuração, especialmente transforms e os arquivos de configuração provavelmente também são relevantes

o que você recomenda em relação à limpeza do cache antes de executar testes em CI

Pessoalmente, acho que é uma boa ideia ter certeza de que não há nada obsoleto por aí dando falsos negativos ou positivos. Faz uma grande diferença para o tempo de execução de seus testes _não_ limpar o cache?

parece ser um pouco mais lento quando executado após a limpeza do cache. obrigado pelas dicas, vou dar uma olhada e ver se posso tentar uma reprodução

FWIW, também notei que a v25 é um pouco mais lenta ou parecida com a v24. Não vi nenhuma melhoria perto de 10-40%.

Eu vi uma aceleração significativa em relação ao dia 24, conforme observado aqui: https://github.com/facebook/jest/issues/7811#issuecomment -577057189

O acima foi testado em osx.

No entanto, a mesma configuração é executada muito, muito mais lentamente em nosso CI que executa o CentOS.

Problema específico do Linux? Problemas relacionados a E / S ao gravar arquivos de cache? É possível desligar completamente a geração de cache para descartar isso?

Acho que encontrei o culpado em nosso caso, é a bandeira --collectCoverage . Quando ele é removido para Jest 24 e 25, nossos testes rodam quase duas vezes mais rápido com menos de 25. Quando está habilitado, nossos testes com menos de 25 são quase 4 vezes mais lentos que os mesmos com menos de 24.

Isso é reproduzível no OSX e no CentOS, portanto, ao contrário do meu comentário anterior, o problema não parece específico do Linux.

Interessante! Atualizamos Istambul para a v3, talvez algo lá tenha regredido. Adicionamos suporte para cobertura de código v8, então eu também posso ter bagunçado a refatoração ao fazer isso

Sim! Isso é consistente com o que estou vendo também. Estamos rodando com cobertura em CI onde é 2x mais lento. E quando corro localmente sem covg é bastante rápido. @SimenB existe alguma opção de configuração para usar o Istanbul antigo? :)

Ecoando o que @csvan disse que seria bom desligar a geração de cache em CI se isso for de fato um culpado, já que o

Não consigo reproduzir isso - os repositórios que testei têm quase o mesmo desempenho com --coverage entre v24 e v25. Alguém seria capaz de montar um repositório com jest 24 e jest 25 em que alternar entre eles mostra uma diferença?

acabei de rodar nosso build de CI com cobertura desabilitada, acho que caminho certo . Os testes são executados às 4:00 com cobertura desligada vs 11 min com cobertura ligada. Vou tentar ver se consigo criar um repro neste fim de semana em algum momento.

nosso exinfo do agente de construção:

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 

Estamos vendo um problema semelhante. Atualizar Jest 25 tornou nossos testes mais lentos ao usar cobertura (166s com Jest 24 contra 381s com Jest 25). Com Jest 25 exibindo muitos desses erros ao executar as verificações:

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 --->

O downgrade para Jest 24 faz com que esses erros desapareçam.

Eu também percebi que Jest 25 lida com collectCoverageFrom diferente, pois parece coletar cobertura de arquivos que desabilitamos explicitamente naquela configuração. O suporte para a sintaxe glob mudou aí?

Algum rastreamento de JS? Seria interessante ver onde morreu.

Também percebi que Jest 25 lida com collectCoverageFrom de maneira diferente, pois parece coletar cobertura de arquivos que desativamos explicitamente nessa configuração. O suporte para a sintaxe glob mudou aí?

Nós atualizamos para Micromatch 4, pode ter mudado algo. Nenhuma mudança de propósito, no entanto. Você poderia abrir um problema separado com uma reprodução?

Algum rastreamento de JS?

Isso foi impresso:

==== 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-...

EDIT : Na verdade, estou vendo erros de heap, mesmo com a cobertura desativada.

Nós atualizamos para Micromatch 4, pode ter mudado algo. Nenhuma mudança de propósito, no entanto. Você poderia abrir um problema separado com uma reprodução?

Vai fazer.

Chiming in novamente. A cobertura é definitivamente mais lenta e parece ser espúria. Aqui estão os horários do 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

Horários para CI (travis).

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

@milesj o que é o circo v25?

É brincadeira de novo corredor, que deveria ser mais rápido, mas nunca é pelo que vi. https://www.npmjs.com/package/jest-circus

@EvHaus Traces do JSDOM é interessante (também pode ser completamente coincidente, é claro). Você poderia tentar instalar jest-environment-jsdom@24 e usar isso? Nós atualizamos de 11 para 15, então algo pode ter mudado. Parece uma possibilidade remota, mas quem sabe

@SimenB Retroceder apenas jest-environment-jsdom para <24.0.0 no meu package.json definitivamente teve um impacto. Os erros heap out of memory desapareceram e Jest parece concluir suas execuções sem nenhum problema.

Interessante! Se você tiver tempo, seria ótimo se você pudesse testar

• 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

Ou apenas vincule jsdom e divida ao meio. Farei isso amanhã, mas ainda não tenho uma boa reprodução

Para os testes a seguir, não tenho a cobertura habilitada.

• Com [email protected]
  
  
  
  • 143s para fazer testes
  
  
  • Sem problemas
  
  
• Com [email protected]
  
  
  
  • 154s para executar testes
  
  
  • Sem problemas
  
  
• Com [email protected]
  
  
  
  • 228s para executar testes
  
  
  • 🚨Muitos JavaScript heap out of memory erros
  
  

Traços de pilha

Estes são alguns dos rastreamentos de pilha da execução de 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 

Espero que isto ajude

Não sei se isso vai ajudar, mas minha organização teve uma desaceleração massiva de Jest 24 para Jest 25 (18 minutos para 28 minutos) que foi embora depois de desligar a coleta de cobertura (para 10 minutos).

@rosasynstylae por curiosidade, seu código tem muitos testes de instantâneo?

@benmonro Sim, sim.

O nosso também! @SimenB , você acha que muitos instantâneos em um repo podem causar isso?

Estamos tendo problemas de desempenho sem instantâneos. No entanto, estamos coletando cobertura. Desaceleração significativa de 24 -> 25. 2 projetos diferentes. Isso varia, mas a desaceleração é significativa e consistente.

Posso executar os testes repetidamente sem alterações e os testes são 10 vezes mais lentos em média do que eram com 24.

Eu volto para 24 e as corridas voltam à velocidade a que estávamos acostumados.

Posso fornecer mais informações, se necessário. Eu queria ter certeza de mencionar nossos 2 projetos sem testes de instantâneo.

De todos os comentários aqui, definitivamente parece que a cobertura é o problema, e provavelmente uma regressão em Istambul.

De todos os comentários aqui, definitivamente parece que a cobertura é o problema, e provavelmente uma regressão em Istambul.

Eu não seria tão rápido em apontar o dedo para Istambul. No meu caso, mesmo com a cobertura desativada, estou observando problemas significativos de desempenho e estabilidade no Jest 25. Consulte https://github.com/facebook/jest/issues/9457#issuecomment -579423330

É possível que haja dois problemas separados:

1) Problemas com jest-environment-jsdom-fourteen, e
2) Problemas com cobertura de Istambul

Eu rebaixei micromatch para ^3.0.0 e vi uma aceleração massiva usando --coverage , mais ou menos de volta ao desempenho que vimos em Jest 24. Alguém pode reproduzir?

ATUALIZAÇÃO: No entanto, agora a execução sem --coverage também está de volta aos 24 níveis de desempenho de Jest - duas vezes mais lento: - /

@EvHaus obrigado por verificar, muito interessante! Ainda não consigo reproduzir isso, infelizmente. Então uma reprodução ainda seria incrível, assim posso tentar depurar isso.

Eu rebaixei micromatch para ^3.0.0 e vi uma aceleração massiva usando --coverage , mais ou menos de volta ao desempenho que vimos em Jest 24. Alguém pode reproduzir?

ATUALIZAÇÃO: No entanto, agora a execução sem --coverage também está de volta aos 24 níveis de desempenho de Jest - duas vezes mais lento: - /

O que diabos ... Pelo que eu posso ver, nada em Istambul depende de micromatch, então por que deveria impactar a cobertura está além de mim 🙁

Toda essa coisa de desempenho de micromatch está ficando um pouco absurda, com cobertura v3 é mais rápido que v4, sem v4 é mais rápido que v3? 😅

@SimenB sim, também

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

para nosso package.json economizou 6 minutos fora da execução ao usar --coverage , trazendo aproximadamente de volta ao que vimos em Jest 24.

Pelo que posso ver, nada em Istambul depende de micromatch

Encontrou este comentário em outro tópico que pode estar relacionado a isto:

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

Apenas confirmei nada no istambul puxa micromatch (eles usam minimatch no plugin do babel).

Pode ser algo sobre exclusões não funcionando corretamente, definitivamente. Nós o usamos para verificar o que devemos instrumentar: https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. Você poderia inserir algum registro lá e ver se retornamos true qualquer lugar com micromatch@4 que não retornamos para micromatch@3 ?

Definitivamente parecem dois problemas separados, um sobre jsdom e outro sobre cobertura

Posso confirmar que está de volta à velocidade normal para nós em CI quando resolvermos a micromatch @ 3 também.

Jest + typescript + react base de código aqui. Ver esse problema e usar npm-force-resolution para forçar a micromatch ^ 3.0.0 pareceu consertar a desaceleração louca.

Você tem padrões de arquivo de teste personalizados e padrões de cobertura em sua configuração?

@EvHaus Estou super interessado em saber se você vê uma diferença ao rebaixar o Micromatch também, visto que você viu uma grande diferença com as versões do jsdom

Se é isso que você quer dizer, sim.

  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/**/**',
  ],

também temos isso e o nosso é bastante semelhante em comprimento / valores

@ Ancient123 sim, exatamente. Parece relacionado à regressão Micromatch para padrões negados. Obrigado!

Parece relacionado à regressão Micromatch para padrões negados. Obrigado!

Observado, vou analisar isso o mais rápido possível.

Toda essa coisa de desempenho de micromatch está ficando um pouco absurda

Desculpe pela degradação do desempenho. Gerar expressões regulares para globbing é muito mais difícil do que parece. Especialmente quando precisa lidar com negação e ser multiplataforma. Estou investigando isso agora.

@jonschlinkert , não foi nada acusatório, o trabalho que você está colocando no Micromatch e nas bibliotecas relacionadas é extremamente apreciado! :coração:

sim! o que @SimenB disse. nada além de ❤️

@EvHaus Estou super interessado em saber se você vê uma diferença ao rebaixar o Micromatch também, visto que você viu uma grande diferença com as versões do jsdom

No meu conjunto package.json i:

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

Execute novamente npm install e, em seguida, exclua manualmente node_modules/jest/micromatch (que estava na versão 4). Em seguida, executei novamente meus testes.

Infelizmente, ainda estou vendo muitos erros de "heap de JavaScript sem memória".

Estou fazendo o downgrade corretamente?

resolutions precisa de yarn , npm ainda não o implementou (está no roteiro para v7: https://blog.npmjs.org/post/186983646370/npm- cli-roadmap-summer-2019)

@EvHaus até o lançamento do npm v7, você pode usar resoluções em npm com este pacote: https://www.npmjs.com/package/npm-force-resolutions

Desculpe pelo atraso. Usou npm-force-resolutions (que está fazendo a coisa certa) para bloquear micromatch na v3. Infelizmente, isso não fez com que meus erros de heap desaparecessem.

Então, para mim, a culpa ainda é [email protected] , conforme mencionado aqui: https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Resolver jsdom para thirteen é o que corrige.

Alguém que experimentou uma degradação de desempenho em 25 tem problemas que não foram corrigidos usando jsdom @ 13 ou micromatch @ 3? Vazamento de memória em JSDOM está sendo corrigido (https://github.com/jsdom/jsdom/pull/2840 e vários problemas / PRs vinculados a ele) e a regressão em micromatch foi relatada e está sendo trabalhada: https: // github.com/micromatch/micromatch/issues/179.

Versão corrigida do JSDOM foi lançada, você pode usá-lo instalando jest-environment-jsdom-sixteen . @EvHaus você poderia verificar se isso corrige seu problema?

@SimenB, meu problema provavelmente não está relacionado, mas tentei jest-environment-jsdom-sixteen usar o padrão e vi um aumento de 20 segundos no tempo de execução para o mesmo conjunto de testes em execuções repetidas.

sobre o uso da v15 (que é o que vem com jest por padrão) e nenhuma outra mudança? Você poderia testar com 16.1.0 também (embora isso vaze memória, pode ser mais difícil de testar). O JSDOM acabou de chegar com suporte a elementos personalizados, _pode_ haver alguma regressão aí? Não tenho certeza

Versão corrigida do JSDOM foi lançada, você pode usá-lo instalando jest-environment-jsdom-sixteen. @EvHaus você poderia verificar se isso corrige seu problema?

Infelizmente, ainda estou recebendo erros de heap com jest-environment-jsdom-sixteen . A última versão estável de trabalho do JSDom para mim é jest-environment-jsdom-thirteen .

Versão corrigida do JSDOM foi lançada, você pode usá-lo instalando jest-environment-jsdom-sixteen . @EvHaus você poderia verificar se isso corrige seu problema?

O ambiente funciona com nossa base de código, mas ainda estamos vendo uma regressão de quase 100% no tempo de execução. Curiosamente, jest-environment-jsdom-sixteen parece melhorar o desempenho do tempo de execução em 10% apenas ao usar 25.1 vs 24.9

Olá @SimenB ,

Criei o caso reproduzível aqui https://github.com/olebedev/jest-perf-issue. Por favor dê uma olhada. Resultado abaixo para comparar. / cc @joscha

Resultados

Os benchmarks foram executados em MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz .

| versão jest | ramo | tempo |
|: -------------- |: ------: | ----------: |
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

Em nosso caso, onde o jest v25.1 era ~ 50% mais lento em comparação com v24.9, agora o jest v25.2.0 mais recente é ainda mais 20% mais lento em comparação com v25.1 🙈

@olebedev Uau, isso é doloroso 😬

Estou recebendo números semelhantes aos seus. Se for baseado em um projeto real, recomendo usar a cobertura v8. Leva o tempo de execução de 600s a 35s na minha máquina em sua reprodução. A razão para a grande diferença é provavelmente que não tentamos instrumentar arquivos não cobertos com cobertura de v8 (apenas dizemos que cada byte está descoberto, o que funciona com v8).

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

Não sei por que é tão lento ... Vou tentar encontrar algum tempo para investigar isso (mas não será tão cedo). Não deve ser pelo menos mais lento na v25 do que na v24

Eu entendi os documentos corretamente que podemos usar a cobertura v8 juntos
com o ambiente ...-sixteen ?

Saúde,
J

Na quarta-feira, 8 de abril de 2020, 22:33 Simen Bekkhus, notificaçõ[email protected] escreveu:

@olebedev https://github.com/olebedev Uau, isso é doloroso 😬

Estou recebendo números semelhantes aos seus. Se for baseado em um projeto real, eu
recomendo o uso de cobertura v8. Leva o tempo de execução de 600s a 35s no meu
máquina em sua reprodução. A razão para a grande diferença é provavelmente que
não tentamos instrumentar arquivos não cobertos com cobertura v8.

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

Não sei por que é tão lento ... Vou tentar encontrar algum tempo para investigar isso.
Não deve ser pelo menos mais lento na v25 do que na v24

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 ou
Cancelar subscrição
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

Sim, jest-environment-jsdom-sixteen ou o pacote jest-environment-node . Observe também que ele só é compatível com o nó 10+, não com o nó 8.

(Eu sempre testei isso apenas com o env do Node, mas se não funcionar com o env do jsdom, isso é um bug - abra um problema separado 🙂)

jest-environment-jsdom-dezesseis + v8 como provedor de cobertura foi pior em cerca de 20% para nós em jest 25.3.0, nó 12.16. Também estamos tentando depurar porque nosso desempenho de teste piorou em cerca de 80% indo de 24 para 25 de brincadeira.

@joual , você tentou a solução alternativa micromatch (downgrade para 3.x)?

Tendo uma experiência semelhante aqui, os tempos de teste (_sem_ cobertura) dobram na v25 de 35-40 segundos para 80-90 e às vezes mais. Tentei bloquear a micromatch na v3, sem diferença mensurável. Fwiw, temos cerca de 3k testes, dos quais 58 são testes de instantâneo.
Tentou fazer o downgrade do jsdom, mas isso parece apresentar muitas interrupções no teste devido aos recursos recentes que estamos usando. Vou ver se consigo contornar isso de alguma forma e relatar de volta.

@SimenB O trabalho de coleta de cobertura em um projeto mais bonito também é muito lento, você pode conferir? https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest coleta cobertura, outro trabalho não.

Tendo uma experiência semelhante aqui, os tempos de teste (_sem_ cobertura) dobram na v25 de 35-40 segundos para 80-90 e às vezes mais. Tentei bloquear a micromatch na v3, sem diferença mensurável. Fwiw, temos cerca de 3k testes, dos quais 58 são testes de instantâneo.
Tentou fazer o downgrade do jsdom, mas isso parece apresentar muitas interrupções no teste devido aos recursos recentes que estamos usando. Vou ver se consigo contornar isso de alguma forma e relatar de volta.

Estava experimentando diferentes versões do jsdom hoje no jest @ 24 (que é v11 por padrão). Até a versão 14, tudo parece funcionar bem, mas a partir da versão 15 os testes demoram de 50 a 60% mais tempo. Mesma história na v16. Vou ver se consigo obter um desempenho semelhante no jest @ 25 , rebaixando o jsdom para v14.

[email protected] tem algumas correções de memória, @EvHaus , você poderia tentar? O próprio --detect-leaks Jest encontra vazamentos em versões anteriores, mas não 16.2.2.

Eu também consegui algumas outras melhorias se você tiver muitos links simbólicos (que são muito lentos no Windows), então se as pessoas pudessem tentar [email protected] seria ótimo 🙂

@SimenB Qual é a maneira mais fácil de testar isso? Se eu adicionar [email protected] diretamente como um devDependency, o Jest ignora isso e usa o que estiver junto com jest-environment-jsdom que é 15.2.1 hoje.

Como posso enganar npm para garantir que está usando a versão jsdom que desejo?

Instale jest-environment-jsdom-sixteen e use-o https://jestjs.io/docs/en/configuration#testenvironment -string

Alpha publicado, então você pode tentar jest@next - ele vem com jsdom 16 fora da caixa

@SimenB Desculpe, não [email protected] e seu [email protected] . Ainda estou recebendo muitos destes erros:

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

E, eventualmente, o corredor morre.

Meus detalhes:

> 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 

Aqui estão algumas das pilhas completas retornadas desses:

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]>,...

Que pena 😞 Isso é com ou sem cobertura?

Isso foi sem cobertura. Deveria ter esclarecido.

Você acha que estou executando uma versão bastante antiga do Node (v10) seria um fator para isso?

Você pode tentar usar versões mais recentes, se nada mais, seria um ponto de dados interessante. Outras coisas a tentar é fazer um despejo de heap antes que ele morra. O que há na pilha?

É interessante que ninguém mencionou que micromatch @ 4 não armazena mais regexps em cache (consulte https://github.com/micromatch/micromatch/pull/151 e https://github.com/facebook/jest/pull/10131 apresenta falta caching no lado do gracejo.

Para mim, fazer downgrade para micromatch @ 3 e atualizar para jest-environment-jsdom-sixteen economizou 50% do tempo.
Mas com o jest 26 e o ​​jsdom integrado ainda recebo o erro de vazamento ao executar o jest com --detectLeaks no meu caso. Tentei repo fresco e tudo funciona bem.

https://github.com/facebook/jest/pull/10131 foi mesclado !! <3

Lançado em 26.1.0, muito interessado em ouvir se isso ajuda as pessoas

@SimenB muito obrigado pelo lançamento! infelizmente, do nosso lado ainda enfrentamos uma grande diferença:

atual:

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

em cada versão superior a 24,9

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

com novos caches e após uma reinstalação completa de todos os módulos de nó. configurações intocadas.
a execução de testes no modo de observação leva mais de 3 minutos na minha máquina para determinar quais testes executar. Não consigo isolar o problema para uma reprodução, mas se você me der alguns conselhos sobre o que testar, eu ficaria muito interessado. obrigado por todo o trabalho que você colocou nisso!

@SimenB

Para prettier projeto, ainda lento do que v24 ao coletar a cobertura.

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

Posso confirmar que o desempenho das versões 25 e 26 é inferior a 24 no Bitbucket Pipeline. Também notei que a lentidão aumenta com a cobertura habilitada. A versão 25 fica ainda pior em comparação com a 26 e o ​​pipeline falha devido ao consumo de memória.

@SimenB Fiz um git bisect para descobrir onde a regressão de desempenho entre 24,9 e 25,1 foi introduzida. Usei os testes mais bonitos porque eles são executados sem modificação de 24,9 a 26,1.

Eu comparei o tempo de execução acumulado de três execuções do subconjunto js (para garantir algum tempo) com o cache desabilitado. Mais especificamente, o comando que uso foi ( yarn run jest --no-cache tests/js/ ) com o nó 10.19. porque o nó 10 era a versão recomendada para 24.9.

Resultados:

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)

Como há um fallback se compileFunction não for definido, removi o branch compileFunction de ad5377333daf6716af3465bba39f86b7db485e2b que restaurou o desempenho.

Olhando para 26.1, o código mudou um pouco, mas compileFunction e o fallback ainda estão lá. Assim:

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

isto é, remover o branch ( patch ) compileFunction traz 26,1 de volta ao tempo de execução de 24,9. Tenho certeza que não é a solução, mas pelo menos temos algo com que trabalhar.

Como outro ponto de dados, nossa suíte jest atualmente leva cerca de 2767 segundos com [email protected] e em nossa atualização MR leva cerca de 3497 segundos, um aumento de cerca de 27%.

Obrigado por todo o excelente trabalho, jest team, espero que as habilidades de detetive de @wurstbonbon possam ajudá-lo a consertar essa regressão!

@wurstbonbon, obrigado por compileFunction é mais lento ... Isso significa que você pode apenas usar um ambiente de teste personalizado em vez de aplicar um patch.

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(e o mesmo para jsdom env). Você pode confirmar?

Embora seja um gargalo, parece estranho - o próprio Node passou a usá-lo 18 meses atrás: https://github.com/nodejs/node/pull/21573. Portanto, é provavelmente algo estranho que estamos fazendo do nosso lado. O link https://github.com/nodejs/node/issues/26229 é muito interessante - talvez precisemos fazer mais caching do nosso lado?

@SimenB acabei de tentar algo semelhante a esse env personalizado e parece que era um pouco melhor (mas ainda mais lento do que o gracejo 24).

Eu tive que fazer MyNodeEnv.prototype.getVmContext = null; , entretanto, porque estou testando com o jest 26 e parece que ele verifica if (typeof this._environment.getVmContext === 'function') { agora . Não tenho certeza se isso poderia causar outros problemas, no entanto.

Estes são os resultados que estou vendo após algumas execuções:

Jest 26 com testEnvironment: "node" => ~ 280s
Jest 26 com ambiente de teste personalizado => ~ 210s
Jest 24 => ~ 160s

Deixe-me saber se eu puder ajudar com alguma outra informação ou algo mais!

Como esperado, o env customizado resulta na mesma aceleração para mais bonito.

Eu também tentei em nossa base de código, onde a diferença é de ~ 270s vs ~ 200s, portanto, apenas cerca de 25% e não 40% de redução. Infelizmente, não posso executar nossos testes com o jest 24 porque contamos com os novos timers modernos de mocking.

Perdi delete no meu exemplo acima, desculpe por isso.

Eu me pergunto se é o suficiente apenas armazenar em cache as funções compiladas manualmente - você poderia tentar aplicar este patch? (JS transpilado e a fonte TS incluída aqui)

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.',
       );

Achei que isso pudesse resolver o problema.

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);
}

Melhora um pouco o desempenho, mas Script ainda é muito mais rápido.

Tentei a recomendação de @SimenB : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs?commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

Embora tenha melhorado um pouco o desempenho, ainda é consideravelmente mais lento do que no gracejo 24.x:

• Jest 24.x: 2580 segundos de tempo de execução total de nossos testes de jest
• Jest 26.x: 3166 segundos de tempo de execução total de nossos testes de jest

@leipert Você por acaso tentou rebaixar o ambiente jsdom para 14?

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" em sua configuração de brincadeira. Isso ainda parece ser responsável pela maior parte do aumento de duração para nós (adiciona 40-50%), mas está começando a parecer que há várias regressões em jogo.

@pleunv Com jest 24.x estamos no jsdom 16 com jest-environment-jsdom-sixteen , tivemos que atualizar devido a alguns problemas com o teste de componentes da web. Portanto, a única mudança que fazemos: jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom , então a versão jsdom nem mesmo muda.

Aberto https://github.com/nodejs/node/issues/35375 upstream sobre o problema encontrado por @wurstbonbon

@SimenB, você está ciente de alguma alternativa viável ao micromatch? Esse repo está em silêncio há mais de meio ano, e os principais problemas que afetam Jest, como https://github.com/micromatch/micromatch/issues/179, ainda estão em aberto.

Na verdade não, é o que a maioria das bibliotecas usa. Poderia olhar, por exemplo, minimatch, mas duvido que seja viável

@SimenB O que torna o micromatch melhor do que todas as alternativas?

Com base no feedback do problema que abri, acho que devemos voltar a usar Script por enquanto, pois parece que será necessário um pouco de trabalho no Node para corrigi-lo.

@leipert @wurstbonbon ou qualquer outra pessoa, você pode tentar este patch em seu 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) {

Eu testei o patch para usar Script em nossas suítes de teste e aqui está o resultado que cheguei
O tempo está em min:sec

Nome Suite 1 | Suite 2 | Suite 3 | Suite 4
- | - | - | - | -
jest 24 | 3:25 | 3:30 | 3:29 | 0:53
jest 26 remendado | 3:32 | 4:36 | 3:48 | 0:53
jest 26 sem patch | 5:10 | 6:12 | 5:11 | 1:07
26 corrigido vs 24 | 4% | 31% | 9% | 1%
26 sem patch vs 24 | 52% | 76% | 49% | 27%
26 com patch e sem patch | 46% | 35% | 36% | 25%

ainda é interessante que a v26 ainda não melhora na v24 ...

Obrigado @Cellule! Isso é bom o suficiente para mim - eu farei um PR quando tiver algum tempo

Coisas incríveis! Isso deixa apenas o problema da Micromatch, espero que o repo entre em manutenção ativa novamente.

BTW, também há regressão de desempenho em JSDOM, eu suponho. Como eu fiz esses testes em um grande projeto da web. Nenhum patch mencionado acima é aplicado.
E era assim que parecia.

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)

Certamente este é um relatório de desempenho super vago e instável que devo ficar, mas acho que cada entrada ajuda :)

https://github.com/facebook/jest/releases/tag/v26.5.0 tem a vm.Script mudança discutida aqui

(Editar: atualizado após execuções adicionais)

Resultados preliminares no mesmo conjunto de testes:

Jest 26,5
Frio: 59.992
Quente: 43.976

Jest 26.4:
Frio: 90,213
Quente: 47,408

Uma aceleração muito significativa em execuções frias <3

E aqui estão os resultados com meu conjunto de testes:

Jest 26,5
Frio: 149s

Jest 26,4
Frio: 226s

Ótimas notícias 🙂 Acho que estamos de volta apenas à regressão micromatch, então

Se vocês estão usando npm-force-resolutions para instalar forçosamente o micromatch 3. Pode não funcionar em [email protected]

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

Erro ao executar o teste:

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 Muito obrigado pela atualização. Isso nos economiza 20% do tempo de execução no Travis depois de atualizar para [email protected]

Nossos resultados:

É v26.5

• 323,98s
• 321,24s

É v24.9

• 262,17s
• 275,96s

Obrigado @SimenB! Isso é incrível. Nossos resultados para nossos ~ 22.000 testes em ~ 2.000 suítes:

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

que é cerca de 3% mais lento e, portanto, na margem de erro, em comparação com a desaceleração de ~ 27% que vimos antes. Obrigado, agora só precisamos fazer a fusão: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Só queria observar que todos os problemas de "pilha sem memória" que eu estava

ATUALIZAÇÃO : esquece. Comecei a receber erros OOM novamente. Acho que está bem no limite do que meu laptop pode suportar e as primeiras execuções foram boas, mas agora está morrendo de novo. Ainda terá que se manter em 24.xx :(

Se alguém estiver interessado, criei um DOM que tem um desempenho muito bom em comparação ao JSDOM. Possui suporte para Jest.

| Operação | JSDOM | Happy DOM |
| ------------------------------------ | ------- | --------- |
| Importar / exigir | 333 ms | 45 ms |
| Analisar HTML | 256 ms | 26 ms |
| Serializar HTML | 65 ms | 8 ms |
| Renderizar elemento personalizado | 214 ms | 19 ms |
| querySelectorAll ('tagname') | 4,9 ms | 0,7 ms |
| querySelectorAll ('. class') | 6,4 ms | 3,7 ms |
| querySelectorAll ('[attribute]') | 4,0 ms | 1,7 ms |
| querySelectorAll ('[class ~ = "nome"]') | 5,5 ms | 2,9 ms |
| querySelectorAll (': nth-child (2n + 1)') | 10,4 ms | 3,8 ms |

Link para o projeto:
https://github.com/capricorn86/happy-dom/

@ capricorn86 Parece bom. É compatível com as especificações?

@ capricorn86 Parece bom. É compatível com as especificações?

Obrigado @milesj!

A funcionalidade que foi implementada foi implementada de acordo com as especificações, mas ainda não há uma visão geral detalhada de quais especificações foram abordadas. Estou pensando em adicionar isso. No entanto, todas as funcionalidades são cobertas por testes de unidade.

O objetivo inicial do DOM era ser capaz de renderizar componentes da web do lado do servidor com bom desempenho, pois eu precisava disso para alguns outros projetos.

FWIW, eu tentei mudar nosso projeto de react-scripts@3 com Jest 24,9, para @react-scripts@4 com Jest 26,6.

Nosso conjunto de testes de API de servidor já estava em execução em cerca de 180-190 segundos. Depois de mudar para Jest 26.6, demorava consistentemente cerca de 220 segundos. Eu até tentei forçar a resolução de minimatch para 4.0.2 . Mudar o executor de teste para jest-circus pareceu funcionar alguns segundos, mas no geral, 26,6 parece visivelmente mais lento.

react-scripts@4 usa jest-circus por padrão, fwiw. Também é micromatch que usamos, não minimatch . Parece que interrompemos a reversão de micromatch via # 10131, portanto, não é tão fácil de testar se essa é mais a causa da regressão

@SimenB : temos uma configuração de migração estranha atm - é um aplicativo MEAN / AngularJS legado que converti para construir usando CRA . A configuração de teste é toda nossa, em comparação com a configuração CRA Jest embutida - estamos apenas aproveitando o fato de que o CRA vem com Jest como uma dependência.

Não estou com minha caixa de trabalho na minha frente, então agora não consigo me lembrar se realmente quis dizer micromatch ou se realmente foquei no nome do pacote errado :) Vou ter que olhar de novo na próxima semana.

Acabei de notar que a v26 é executada _muito_ mais lentamente no iTerm do que no terminal padrão do macOS. Em um conjunto de 6.500 testes, obtenho consistentemente os seguintes resultados:

• v24, Terminal: ~ 90s
• v24, iTerm2: ~ 90s
• v26, Terminal: ~ 110s
• v26, iTerm2: ~ 150s

Isso me surpreendeu um pouco depois de meses tentando várias coisas para resolver a desaceleração. Alguma chance de alguém com problemas de desempenho em um Mac tentar fazer isso? Veja bem, isso é com jsdom @ 14 na v26.

@pleunv Eu acredito que isso pode estar relacionado: https://github.com/facebook/jest/pull/9294. Percebi que os hiperlinks tornam o iTerm2 mais lento na minha máquina, tornando-a instável. Mas não investiguei a velocidade geral de execução, nem encontrei outra pessoa que teve problemas com isso.

Eureka. Pesquisar "iTerm" me trouxe a este PR . Eu já tinha notado esses sublinhados antes e não percebi que eram hiperlinks. Depois de ver esse PR, desativei os hiperlinks no iTerm, o que reduziu meu tempo de execução para 130 segundos. Depois de aplicar o código do PR e remover os hiperlinks, estou de volta aos 120s. Sanidade ligeiramente restaurada.

Alguma chance do RP ser colocado de volta?

editar: @thymikee antes de mim 😄

@pleunv Vou tentar encontrar algum tempo esta semana para trazê-lo de volta. Embora o negócio real seja consertar isso para o iTerm, já que outros terminais, por exemplo, no Linux, não têm problemas com hiperlinks. Você se importaria de registrar um problema para o projeto iTerm?

Acabei de fazer essa alteração e me deu 1s para um único arquivo de teste. E você ainda pode clicar no url, apenas não está mais sublinhado.

Isso pode ser enorme para execuções maiores. ❤️

//editar
Engraçado, não fazia diferença antes se era iterm ou terminal. Após a mudança, o iterm fica mais rápido para mim.

@pleunv Vou tentar encontrar algum tempo esta semana para trazê-lo de volta. Embora o negócio real seja consertar isso para o iTerm, já que outros terminais, por exemplo, no Linux, não têm problemas com hiperlinks. Você se importaria de registrar um problema para o projeto iTerm?

Eu criei um problema aqui (eles estão no GitLab). Se alguém tiver detalhes adicionais ou um projeto de reprodução, fique à vontade para adicioná-los.

Eu estava experimentando um pouco mais nesse meio tempo e descobri que, ao executá-lo apenas em um subconjunto menor de testes (algumas dezenas de arquivos de teste), os hiperlinks geralmente não fazem muita diferença. Ao executá-lo em nosso conjunto completo (700 arquivos), o impacto é muito mensurável.

Também tenho a impressão de que com o passar do tempo a saída do console de jest começa a ficar realmente falha / chamativa. As linhas de progresso na parte inferior, por exemplo, são mais ocultas do que visíveis.