<p>hay una actuación de 25</p>

Perdón por la regresión pero

lo siento, no puedo compartir nuestro código base

significa que no podemos hacer absolutamente nada. Esta es la primera vez que escucho que el rendimiento retrocede, en todos los demás lugares he escuchado de un 10-40% de _mejora_ en el rendimiento que pasa de 24 a 25. Debe proporcionar algún tipo de reproducción, de lo contrario, tendremos que cerrar este problema. ya que no es procesable en absoluto tal como está.

Si desea ver esto abordado, tendrá que dedicar algún tiempo a armar un estuche de reproducción, o esperar que alguien más lo haga.

ok, veré si puedo sacar nuestras 10 pruebas más lentas, y luego intentar ejecutarlas en 24 vs 25. Mientras tanto, ¿qué recomiendas con respecto a borrar el caché antes de ejecutar las pruebas en CI? ¿hazlo? no lo hagas

Su configuración, especialmente transforms y los archivos de instalación probablemente también sean relevantes

¿Qué recomienda con respecto a borrar el caché antes de ejecutar pruebas en CI?

Personalmente, creo que es una buena idea asegurarse de que no haya nada rancio que dé falsos negativos o positivos. ¿Hace una gran diferencia en el tiempo de ejecución de sus pruebas el _no_ borrar la caché?

parece ser un poco más lento cuando se ejecuta después de borrar el caché. gracias por los consejos, lo investigaré y veré si puedo intentar una reproducción

FWIW, también he notado que la v25 es un poco más lenta o está a la par con la v24. No he visto una mejora cercana al 10-40%.

Vi una aceleración significativa sobre la broma 24 como se indica aquí: https://github.com/facebook/jest/issues/7811#issuecomment -577057189

Lo anterior se probó en osx.

Sin embargo, la misma configuración exacta se ejecuta mucho, mucho más lento en nuestro CI que ejecuta CentOS.

¿Problema específico de Linux? ¿Problemas relacionados con E / S al escribir archivos de caché? ¿Es posible desactivar la generación de caché por completo para descartar esto?

Creo que encontré al culpable en nuestro caso, es la bandera --collectCoverage . Cuando se elimina tanto para Jest 24 como para 25, nuestras pruebas se ejecutan aproximadamente el doble de rápido por debajo de 25. Cuando está habilitado, nuestras pruebas por debajo de 25 son casi 4 veces más lentas que las mismas por debajo de 24.

Esto es reproducible tanto en OSX como en CentOS, por lo que, contrariamente a mi comentario anterior, el problema no parece específico de Linux.

¡Interesante! Hemos actualizado Estambul a v3, tal vez algo haya retrocedido. Hemos agregado soporte para la cobertura del código v8, por lo que también podría haber estropeado la refactorización al hacerlo.

¡Sí! Eso es consistente con lo que estoy viendo también. Estamos funcionando con cobertura en CI, donde es 2 veces más lento. Y cuando ejecuto localmente sin covg es bastante rápido. @SimenB, ¿hay alguna opción de configuración para usar la antigua Estambul? :)

Haciendo eco de lo que dijo @csvan , sería bueno desactivar la generación de caché en CI si eso es de hecho un culpable, ya que lo eliminamos antes de compilar de todos modos

No puedo reproducir esto: los repositorios que pruebo tienen aproximadamente el mismo rendimiento con --coverage entre v24 y v25. ¿Alguien podría armar un repositorio con jest 24 y jest 25 donde cambiar entre ellos muestra una diferencia?

acabo de ejecutar nuestra compilación de CI con cobertura deshabilitada, creo que @csvan está en algo. Las pruebas se ejecutan a las 4:00 con cobertura desactivada frente a 11 minutos con cobertura activada. Intentaré ver si puedo crear una reproducción este fin de semana en algún momento.

nuestro exinfo del agente de compilación:

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 viendo un problema similar. La actualización de Jest 25 hizo que nuestras pruebas fueran más lentas al usar la cobertura (166 con Jest 24 frente a 381 con Jest 25). Con Jest 25 mostrando muchos de estos errores al ejecutar las comprobaciones:

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

La degradación a Jest 24 hace que esos errores desaparezcan.

También noté que Jest 25 maneja collectCoverageFrom diferente, ya que parece recopilar cobertura de archivos que hemos deshabilitado explícitamente en esa configuración. ¿El soporte para la sintaxis glob cambió allí?

¿Algún rastro de JS en absoluto? Sería interesante ver dónde murió.

También noté que Jest 25 maneja collectCoverageFrom de manera diferente, ya que parece recopilar cobertura de archivos que hemos deshabilitado explícitamente en esa configuración. ¿El soporte para la sintaxis glob cambió allí?

Actualizamos a Micromatch 4, podría haber cambiado algo. Sin embargo, no hay cambios a propósito. ¿Podrías abrir un número aparte con una reproducción?

¿Algún rastro de JS en absoluto?

Esto fue impreso:

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

EDITAR : En realidad, veo errores de montón incluso con la cobertura deshabilitada.

Actualizamos a Micromatch 4, podría haber cambiado algo. Sin embargo, no hay cambios a propósito. ¿Podrías abrir un número aparte con una reproducción?

Servirá.

Entrando de nuevo. La cobertura es definitivamente más lenta y parece ser falsa. Aquí están los tiempos para 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

Tiempos de CI (travis).

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

@milesj ¿que es v25 circus?

Es un corredor nuevo de bromas, que se supone que es más rápido, pero nunca lo es por lo que he visto. https://www.npmjs.com/package/jest-circus

@EvHaus Traces de JSDOM es interesante (también puede ser una coincidencia total, por supuesto). ¿Podrías intentar instalar jest-environment-jsdom@24 y usarlo? Pasamos de 11 a 15, por lo que algo podría haber cambiado. Parece una posibilidad remota, pero quién sabe

@SimenB Revertir solo jest-environment-jsdom a <24.0.0 en mi package.json definitivamente tuvo un impacto. Los errores heap out of memory han desaparecido y Jest parece completar sus ejecuciones sin ningún problema.

¡Interesante! Si tienes tiempo, sería maravilloso si pudieras probar

• 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

O simplemente enlaza jsdom y biseca. Lo haré mañana, pero todavía no tengo una buena reproducción.

Para las siguientes pruebas, no tengo la cobertura habilitada.

• Con [email protected]
  
  
  
  • 143 para ejecutar pruebas
  
  
  • Sin problemas
  
  
• Con [email protected]
  
  
  
  • 154 para ejecutar pruebas
  
  
  • Sin problemas
  
  
• Con [email protected]
  
  
  
  • 228 para ejecutar pruebas
  
  
  • 🚨Muchos JavaScript heap out of memory errores
  
  

Rastros de pila

Estos son algunos de los seguimientos de pila de la ejecución 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 esto ayude

No sé si esto ayudará, pero mi organización tuvo una ralentización masiva de Jest 24 a Jest 25 (18 minutos a 28 minutos) que desapareció después de desactivar la recopilación de cobertura (hasta 10 minutos).

@rosasynstylae por curiosidad, ¿tu código tiene muchas pruebas de instantáneas?

@benmonro Sí, sí.

¡También el nuestro! @SimenB , ¿crees que muchas instantáneas en un repositorio podrían causar esto?

Tenemos problemas de rendimiento sin instantáneas. Sin embargo, estamos recopilando cobertura. Ralentización significativa de 24 -> 25. 2 proyectos diferentes. Varía, pero la desaceleración es significativa y constante.

Puedo ejecutar las pruebas una y otra vez sin cambios y las pruebas son 10 veces más lentas en promedio que con 24.

Vuelvo a 24 y las carreras vuelven a la velocidad a la que estábamos acostumbrados.

Puedo proporcionar más información si es necesario. Quería asegurarme de mencionar nuestros 2 proyectos sin pruebas de instantáneas.

De todos los comentarios aquí, definitivamente parece que la cobertura es el problema, y ​​probablemente una regresión en Estambul.

De todos los comentarios aquí, definitivamente parece que la cobertura es el problema, y ​​probablemente una regresión en Estambul.

No sería tan rápido para señalar con el dedo a Estambul. En mi caso, incluso con la cobertura desactivada, veo problemas importantes de rendimiento y estabilidad en Jest 25. Consulte https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Es posible que haya dos problemas separados:

1) Problemas con jest-environment-jsdom-catorce, y
2) Problemas con la cobertura de Estambul

Bajé micromatch a ^3.0.0 y vi una aceleración masiva usando --coverage , más o menos al rendimiento que vimos en Jest 24. ¿Alguien puede reproducir?

ACTUALIZACIÓN: Sin embargo, ahora que se ejecuta sin --coverage también ha vuelto a los niveles de rendimiento de Jest 24, el doble de lento: - /

@EvHaus gracias por comprobar, muy interesante! Todavía no puedo reproducir esto, desafortunadamente. Entonces, una reproducción aún sería increíble, de esa manera puedo intentar depurar esto.

Bajé micromatch a ^3.0.0 y vi una aceleración masiva usando --coverage , más o menos al rendimiento que vimos en Jest 24. ¿Alguien puede reproducir?

ACTUALIZACIÓN: Sin embargo, ahora que se ejecuta sin --coverage también ha vuelto a los niveles de rendimiento de Jest 24, el doble de lento: - /

Qué en el mundo ... Por lo que puedo ver, nada en Estambul depende de micromatch, así que no entiendo por qué debería afectar la cobertura 🙁

Todo el asunto del rendimiento de micromatch se está volviendo un poco absurdo, ¿con cobertura v3 es más rápida que v4, sin v4 es más rápida que v3? 😅

@SimenB sí, lo ejecuté a través de nuestro CI también solo para confirmar. No cambiar nada más que agregar

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

to our package.json redujo 6 minutos sólidos de la ejecución al usar --coverage , lo que lo devolvió aproximadamente a lo que vimos en Jest 24.

Por lo que puedo ver, nada en Estambul depende de micromatch

Encontré este comentario en otro hilo que puede estar relacionado con esto:

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

Acabo de confirmar que nada en estambul extrae micromatch (usan minimatch en el complemento de babel).

Definitivamente, podría deberse a que las exclusiones no funcionan correctamente. Lo usamos para verificar qué debemos instrumentar: https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. ¿Podrías poner un poco de registro allí y ver si devolvemos true cualquier lugar con micromatch@4 que no lo hacemos por micromatch@3 ?

Sin embargo, definitivamente se siente como dos problemas separados, uno sobre jsdom y otro sobre cobertura

Puedo confirmar que ha vuelto a la velocidad normal para nosotros en CI cuando también resolvemos micromatch @ 3 .

Jest + mecanografiado + react codebase aquí. Ver este problema y usar npm-force-resolution para forzar micromatch ^ 3.0.0 pareció solucionar la loca desaceleración.

¿Tiene patrones de archivo de prueba personalizados o patrones de cobertura en su configuración?

@EvHaus Estoy muy interesado en si ve una diferencia al degradar también Micromatch, ya que vio una gran diferencia con las versiones de jsdom

Si esto es lo que quieres decir, entonces sí.

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

también tenemos eso y el nuestro se ve bastante similar en longitud / valores

@ Ancient123 sí, exactamente. Parece relacionado con la regresión de Micromatch para patrones negados. ¡Gracias!

Parece relacionado con la regresión de Micromatch para patrones negados. ¡Gracias!

Notado, lo investigaré lo antes posible.

Todo el asunto del rendimiento del micromatch se está volviendo un poco absurdo

Perdón por la degradación del rendimiento. Generar expresiones regulares para globbing es mucho más difícil de lo que parece. Especialmente cuando necesita manejar la negación y ser multiplataforma. Estoy investigando esto ahora.

@jonschlinkert , no pretendía acusarlo en absoluto, ¡el trabajo que está poniendo en Micromatch y las bibliotecas relacionadas es muy apreciado! :corazón:

¡sí! lo que dijo @SimenB . nada más que ❤️

@EvHaus Estoy muy interesado en si ve una diferencia al degradar también Micromatch, ya que vio una gran diferencia con las versiones de jsdom

En mi package.json puse:

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

Se volvió a ejecutar npm install , y luego se eliminó manualmente node_modules/jest/micromatch (que estaba en la versión 4). Luego volví a ejecutar mis pruebas.

Desafortunadamente, sigo viendo muchos errores de "pila de JavaScript sin memoria".

¿Estoy haciendo la degradación correctamente?

resolutions necesita yarn , npm aún no lo ha implementado (está en la hoja de ruta para v7: https://blog.npmjs.org/post/186983646370/npm- cli-roadmap-verano-2019)

@EvHaus hasta que salga npm v7, puede usar resoluciones en npm con este paquete: https://www.npmjs.com/package/npm-force-resolutions

Pido disculpas por la demora. Usó npm-force-resolutions (que está haciendo lo correcto) para bloquear micromatch a v3. Desafortunadamente, no hizo que desaparecieran mis errores de montón.

Entonces, para mí, todavía es [email protected] culpable, como se menciona aquí: https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Resolver jsdom a thirteen es lo que lo soluciona.

¿Alguien que haya experimentado una degradación del rendimiento en 25 tiene problemas que no se solucionan al usar jsdom @ 13 o micromatch @ 3? Se está arreglando la fuga de memoria en JSDOM (https://github.com/jsdom/jsdom/pull/2840 y varios problemas / PR vinculados desde él) y se ha informado y se está trabajando en la regresión en micromatch: https: // github.com/micromatch/micromatch/issues/179.

Se ha lanzado una versión fija de JSDOM, puede usarla instalando jest-environment-jsdom-sixteen . @EvHaus, ¿ podría verificar que soluciona su problema?

@SimenB, mi problema probablemente no esté relacionado, pero probé jest-environment-jsdom-sixteen comparación con el uso predeterminado, y vi un aumento de 20 segundos en el tiempo de ejecución para el mismo conjunto de pruebas en ejecuciones repetidas.

sobre el uso de v15 (que es lo que se envía con broma por defecto) y no hay otros cambios? ¿Podría probar con 16.1.0 también (aunque eso pierde memoria, por lo que podría ser más difícil de probar)? JSDOM acaba de aterrizar con soporte de elementos personalizados, ¿podría haber alguna regresión allí? No estoy seguro

Se ha lanzado una versión fija de JSDOM, puede usarla instalando jest-environment-jsdom-sixteen. @EvHaus, ¿ podría verificar que soluciona su problema?

Desafortunadamente, todavía aparecen errores de montón con jest-environment-jsdom-sixteen . La última versión de trabajo estable de JSDom para mí es jest-environment-jsdom-thirteen .

Se ha lanzado una versión fija de JSDOM, puede usarla instalando jest-environment-jsdom-sixteen . @EvHaus, ¿ podría verificar que soluciona su problema?

El entorno funciona con nuestro código base, pero seguimos viendo una regresión de casi el 100% en tiempo de ejecución. Anecdóticamente, jest-environment-jsdom-sixteen parece mejorar el rendimiento del tiempo de ejecución en un 10% ish solo cuando se usa 25.1 vs 24.9

Hola @SimenB ,

Hice el caso reproducible aquí https://github.com/olebedev/jest-perf-issue. Por favor echa un vistazo. Debajo del resultado para comparar. / cc @joscha

Resultados

Los puntos de referencia se ejecutaron en MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz .

| versión de broma | rama | tiempo |
|: -------------- |: ------: | ----------: |
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

En nuestro caso, donde jest v25.1 era ~ 50% más lento en comparación con v24.9, ahora el último jest v25.2.0 es incluso un 20% más lento en comparación con v25.1 🙈

@olebedev Woah, eso es doloroso 😬

Recibo números similares a los tuyos. Si se basa en un proyecto real, recomiendo usar cobertura v8. Toma el tiempo de ejecución de 600 a 35 segundos en mi máquina en su reproducción. La razón de la enorme diferencia es probablemente que no intentamos instrumentar archivos no cubiertos con cobertura v8 (solo decimos que cada byte está descubierto, lo que funciona con v8).

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

No estoy seguro de por qué es tan lento ... intentaré encontrar algo de tiempo para investigarlo (aunque no lo haré pronto). Al menos no debería ser más lento en v25 que en v24

¿Entiendo correctamente los documentos de que podemos usar la cobertura v8 juntos?
con el entorno ...-sixteen ?

Salud,
J

El miércoles 8 de abril de 2020, 22:33 Simen Bekkhus, [email protected] escribió:

@olebedev https://github.com/olebedev Woah, eso es doloroso 😬

Recibo números similares a los tuyos. Si se basa en un proyecto real,
recomiendo usar la cobertura v8. Toma el tiempo de ejecución de 600 a 35 s en mi
máquina en su reproducción. La razón de la enorme diferencia es probablemente que
no intentamos instrumentar archivos no cubiertos con cobertura v8.

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

No estoy seguro de por qué es tan lento ... Intentaré encontrar algo de tiempo para investigarlo.
Al menos no debería ser más lento en v25 que en v24

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

Sí, ya sea jest-environment-jsdom-sixteen , o el paquete jest-environment-node . También tenga en cuenta que solo es compatible con el nodo 10+, no con el nodo 8.

(Alguna vez solo probé esto con Node env, pero si no funciona con jsdom env, eso es un error, abra un problema por separado 🙂)

jest-environment-jsdom-sixteen + v8 ya que el proveedor de cobertura fue peor en aproximadamente un 20% para nosotros en jest 25.3.0, nodo 12.16. También estamos tratando de depurar por qué nuestro rendimiento de prueba empeoró en aproximadamente un 80% al pasar de 24 a 25.

@joual , ¿probaste la solución alternativa de micromatch (rebajar a 3.x)?

Al tener una experiencia similar aquí, los tiempos de prueba (_sin_ cobertura) se duplican en v25 de 35-40 segundos a 80-90 y, a veces, más. Intenté bloquear el micromatch en v3, sin diferencia medible. Fwiw, tenemos alrededor de 3000 pruebas de las cuales 58 son instantáneas.
Intenté degradar jsdom, pero esto parece introducir muchas fallas en las pruebas debido a las funciones recientes que hemos estado usando. Veré si puedo solucionar esto de alguna manera e informar.

@SimenB El trabajo de recolección de cobertura en un proyecto más bonito también es muy lento, ¿puedes verificarlo? https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest cobra cobertura, otros trabajos no.

Al tener una experiencia similar aquí, los tiempos de prueba (_sin_ cobertura) se duplican en v25 de 35-40 segundos a 80-90 y, a veces, más. Intenté bloquear el micromatch en v3, sin diferencia medible. Fwiw, tenemos alrededor de 3000 pruebas de las cuales 58 son instantáneas.
Intenté degradar jsdom, pero esto parece introducir muchas fallas en las pruebas debido a las funciones recientes que hemos estado usando. Veré si puedo solucionar esto de alguna manera e informar.

Estaba experimentando con diferentes versiones de jsdom hoy en jest @ 24 (que es v11 por defecto). Hasta la versión 14, todo parece funcionar bien, pero a partir de la versión 15, las ejecuciones de prueba tardan constantemente entre un 50 y un 60% más. Misma historia en v16. Veré si puedo obtener un rendimiento similar en jest @ 25 degradando jsdom a v14.

[email protected] tiene algunas correcciones de memoria, @EvHaus , --detect-leaks Jest encuentra fugas en versiones anteriores, pero no en la 16.2.2.

También obtuve algunas otras mejoras si tiene muchos enlaces simbólicos (lo cual es muy lento en Windows), así que si la gente pudiera probar [email protected] sería genial 🙂

@SimenB ¿Cuál es la forma más fácil de probar eso? Si agrego [email protected] directamente como devDependency, Jest lo ignora y usa lo que esté incluido con jest-environment-jsdom que es 15.2.1 hoy.

¿Cómo puedo engañar a npm para asegurarme de que está usando la versión de jsdom que quiero?

Instale jest-environment-jsdom-sixteen y utilícelo https://jestjs.io/docs/en/configuration#testenvironment -string

Alpha publicado, así que puedes probar jest@next - viene con jsdom 16 listo para usar

@SimenB Lo siento, no mucha suerte con [email protected] y su [email protected] . Sigo recibiendo muchos de estos errores:

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

Y finalmente el corredor muere.

Mis detalles:

> 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 

Estas son algunas de las pilas completas devueltas de esos:

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

Lástima 😞 ¿Eso es con o sin cobertura?

Eso fue sin cobertura. Debería haberlo aclarado.

¿Crees que estoy ejecutando una versión bastante antigua de Node (v10) que sería un factor en esto?

Puede intentar usar versiones más nuevas, como mínimo, sería un punto de datos interesante. Otras cosas que puede intentar es intentar hacer un volcado de pila justo antes de que muera. ¿Qué hay en el montón?

Es interesante que nadie haya mencionado que micromatch @ 4 ya no almacena en caché las expresiones regulares (consulte https://github.com/micromatch/micromatch/pull/151 y https://github.com/facebook/jest/pull/10131 introduce la falta almacenamiento en caché en el lado de la broma.

Para mí, cambiar a jest-environment-jsdom-sixteen ahorró el 50% del tiempo.
Pero con jest 26 y jsdom incorporado, todavía recibo un error de fugas cuando ejecuto jest con --detectLeaks en mi caso. Probé un nuevo repositorio y todo funciona bien.

https://github.com/facebook/jest/pull/10131 se fusiona !! <3

Lanzado en 26.1.0, muy interesado en escuchar si ayuda a la gente

@SimenB ¡muchas gracias por el lanzamiento! lamentablemente, de nuestro lado, todavía nos enfrentamos a una gran diferencia:

Actual:

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

en todas las versiones superiores a 24,9

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

ambos con cachés nuevos y después de una reinstalación completa de todos los módulos de nodo. configuraciones intactas.
ejecutando pruebas en modo reloj, se necesitan más de 3 minutos en mi máquina para determinar qué pruebas ejecutar. Realmente no puedo aislar el problema para una reproducción, pero si me dan algunos consejos sobre qué probar, estaría muy interesado. ¡Gracias por todo el trabajo que pusiste en eso!

@SimenB

Para el proyecto prettier , aún es más lento que v24 al cobrar la cobertura.

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

Puedo confirmar que los rendimientos de las versiones 25 y 26 son inferiores a 24 en Bitbucket Pipeline. También he notado que la lentitud aumenta con la cobertura habilitada. La versión 25 empeora aún más en comparación con la 26 y la canalización se bloquea debido al consumo de memoria.

@SimenB Hice un git bisect para averiguar dónde se introdujo la regresión de rendimiento entre 24,9 y 25,1. Usé las pruebas más bonitas porque se ejecutan sin modificaciones desde 24.9 hasta 26.1.

Comparé el tiempo de ejecución acumulado de tres ejecuciones del subconjunto js (para ahorrar algo de tiempo) con el caché deshabilitado. Más especialmente, el comando que utilizo fue ( yarn run jest --no-cache tests/js/ ) con el nodo 10.19. porque el nodo 10 era la versión 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 hay un respaldo si compileFunction no está definido, eliminé la rama compileFunction de ad5377333daf6716af3465bba39f86b7db485e2b que restauró el rendimiento.

Mirando 26.1, el código se ha movido un poco, pero compileFunction y el respaldo todavía están allí. Entonces:

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

es decir, eliminar la rama compileFunction ( parche ) devuelve 26.1 al tiempo de ejecución de 24.9. Estoy seguro de que esa no es la solución, pero al menos tenemos algo con lo que trabajar.

Como otro punto de datos, nuestro paquete de bromas actualmente toma alrededor de 2767 segundos con en nuestra actualización MR tarda alrededor de 3497 segundos, un aumento de alrededor del 27%.

Gracias por todo el gran trabajo, equipo de broma, ¡espero que las habilidades de detective de @wurstbonbon puedan ayudarlo a solucionar esa regresión!

@wurstbonbon ¡ Gracias por tomarse el tiempo de excavar! Es muy interesante que compileFunction sea ​​más lento ... Eso debería significar que puede usar un entorno de prueba personalizado en lugar de aplicar un parche.

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(y lo mismo para jsdom env). ¿Puedes confirmar?

Sin embargo, ser un cuello de botella suena extraño: el propio Node cambió a usarlo hace 18 meses: https://github.com/nodejs/node/pull/21573. Así que probablemente sea algo extraño que estamos haciendo de nuestro lado. Sin embargo, el https://github.com/nodejs/node/issues/26229 vinculado es muy interesante, ¿tal vez necesitemos hacer más almacenamiento en caché de nuestro lado?

@SimenB acabo de probar algo similar a ese env personalizado y parece que fue un poco mejor (pero aún más lento que broma 24).

Que tenía que hacer MyNodeEnv.prototype.getVmContext = null; , sin embargo, porque estoy probando con broma 26, y parece que se comprueba if (typeof this._environment.getVmContext === 'function') { ahora . Sin embargo, no estoy seguro de si esto podría causar otros problemas.

Estos son los resultados que estoy viendo después de algunas ejecuciones:

Jest 26 w / testEnvironment: "nodo" => ~ 280 s
Jest 26 con entorno de prueba personalizado => ~ 210 s
Broma 24 => ~ 160 s

¡Avíseme si puedo ayudar con cualquier otra información o algo más!

Como se esperaba, el entorno personalizado da como resultado la misma aceleración para más bonito.

También lo probé en nuestro código base, donde la diferencia es ~ 270 s vs ~ 200 s, por lo que solo se reduce el 25% y no el 40%. Desafortunadamente, no puedo ejecutar nuestras pruebas con Jest 24 porque confiamos en los nuevos temporizadores modernos que se burlan.

Me perdí un delete en mi ejemplo anterior, lo siento.

Me pregunto si es suficiente almacenar en caché las funciones compiladas manualmente. ¿Podría intentar aplicar este parche? (tanto JS transpilado como la fuente TS incluida aquí)

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

Pensé que esto podría funcionar.

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

Mejora un poco el rendimiento, pero Script sigue siendo mucho más rápido.

Probé la recomendación de @SimenB : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs?commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

Si bien mejoró un poco el rendimiento, sigue siendo considerablemente más lento que en jest 24.x:

• Jest 24.x: 2580 segundos de tiempo total de ejecución de nuestras pruebas de broma
• Broma 26.x: 3166 segundos de tiempo de ejecución total de nuestras pruebas de broma

@leipert ¿Ha intentado por casualidad degradar el entorno jsdom a 14?

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" en su configuración de broma. Esto todavía parece ser responsable de la mayor parte del aumento de duración para nosotros (agrega 40-50%) pero está comenzando a parecer que hay múltiples regresiones en juego.

@pleunv Con jest 24.x estamos en jsdom 16 con jest-environment-jsdom-sixteen , tuvimos que actualizar debido a algunos problemas con las pruebas de componentes web. Entonces, el único cambio que hacemos: jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom , por lo que la versión de jsdom ni siquiera cambia.

Abrió https://github.com/nodejs/node/issues/35375 upstream sobre el problema encontrado por @wurstbonbon

@SimenB , ¿conoce alguna alternativa viable a micromatch? Ese repositorio ha estado en silencio durante más de medio año, y los principales problemas que afectan a Jest, como https://github.com/micromatch/micromatch/issues/179 , aún están abiertos.

En realidad, no, es lo que utilizan la mayoría de las bibliotecas. Podría mirar, por ejemplo, minimatch, pero dudo que sea viable

@SimenB ¿Qué hace que micromatch sea mejor que todas las alternativas?

Según los comentarios sobre el problema que abrí, creo que deberíamos volver a usar Script por ahora, ya que parece que será necesario trabajar un poco en Node para solucionarlo allí.

@leipert @wurstbonbon o cualquier otra persona, ¿puedes probar este parche en tu 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) {

Probé el parche para usar Script en nuestras suites de prueba y aquí está el resultado al que llegué
El tiempo está en min:sec

Nombre | Suite 1 | Suite 2 | Suite 3 | Suite 4
- | - | - | - | -
broma 24 | 3:25 | 3:30 | 3:29 | 0:53
broma 26 parcheado | 3:32 | 4:36 | 3:48 | 0:53
broma 26 sin parche | 5:10 | 6:12 | 5:11 | 1:07
26 parcheado vs 24 | 4% | 31% | 9% | 1%
26 sin parche vs 24 | 52% | 76% | 49% | 27%
26 parcheado o sin parche | 46% | 35% | 36% | 25%

sigue siendo interesante que v26 todavía no mejora en v24 ...

¡Gracias @Cellule! Eso es lo suficientemente bueno para mí: armaré un PR cuando tenga algo de tiempo

¡Cosas geniales! Eso deja solo el problema de Micromatch, con suerte, ese repositorio volverá a estar bajo mantenimiento activo.

Por cierto, también hay una regresión de rendimiento en JSDOM, supongo. Como hice tales pruebas en un gran proyecto web. No se aplican los parches mencionados anteriormente.
Y se veía así.

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)

Seguramente este es un informe de desempeño súper vago e inestable que debo quedarme, pero creo que cada entrada ayuda :)

https://github.com/facebook/jest/releases/tag/v26.5.0 tiene el cambio vm.Script discutido aquí

(Editar: actualizado después de ejecuciones adicionales)

Resultados preliminares en el mismo conjunto de pruebas:

Broma 26.5
Frío: 59.992
Caliente: 43.976

Broma 26.4:
Frío: 90.213
Caliente: 47.408

Una aceleración muy significativa en carreras en frío <3

Y aquí están los resultados con mi conjunto de pruebas:

Broma 26.5
Frío: 149 s

Broma 26.4
Frío: 226 s

Buenas noticias 🙂 Creo que volvemos a la regresión de micromatch, entonces

Si están usando npm-force-resolutions para instalar forzosamente micromatch 3. Es posible que no funcione en [email protected]

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

Error al ejecutar la prueba:

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 Muchas gracias por la actualización. Nos ahorra un 20% del tiempo de ejecución en Travis después de actualizar a [email protected]

Nuestros resultados:

Es v26.5

• 323,98 s
• 321,24 s

Es v24.9

• 262.17s
• 275,96 s

¡Gracias @SimenB! Esto es increíble. Nuestros resultados para nuestras ~ 22000 pruebas en ~ 2000 suites:

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

que es aproximadamente un 3% más lento y, por lo tanto, está en el margen de error, en comparación con el ~ 27% de desaceleración que vimos antes. Gracias, ahora solo necesitamos fusionar: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Solo quería señalar que todos los problemas de "almacenamiento sin memoria" que tenía antes desaparecieron después de actualizar a Jest 26.5.2 y al Nodo 14 (antes estaba en el Nodo 10). No estoy seguro de cuánto del problema fue causado por Jest frente a Node, pero si otros están viendo problemas similares, intente actualizar a ambos.

ACTUALIZACIÓN : No importa. Empecé a recibir errores OOM nuevamente. Supongo que está justo en el límite de lo que mi computadora portátil puede manejar y las primeras ejecuciones fueron buenas, pero ahora está muriendo nuevamente. Tendrá que ceñirse a 24.xx :(

Si alguien está interesado, he creado un DOM que tiene muy buen rendimiento en comparación con JSDOM. Tiene soporte para Jest.

| Operación | JSDOM | Happy DOM |
| ------------------------------------ | ------- | --------- |
| Importar / Requerir | 333 ms | 45 ms |
| Analizar HTML | 256 ms | 26 ms |
| Serializar HTML | 65 ms | 8 ms |
| Render elemento personalizado | 214 ms | 19 ms |
| querySelectorAll ('nombre de etiqueta') | 4,9 ms | 0,7 ms |
| querySelectorAll ('. class') | 6,4 ms | 3,7 ms |
| querySelectorAll ('[atributo]') | 4,0 ms | 1,7 ms |
| querySelectorAll ('[class ~ = "nombre"]') | 5,5 ms | 2,9 ms |
| querySelectorAll (': n-ésimo hijo (2n + 1)') | 10,4 ms | 3,8 ms |

Enlace al proyecto:
https://github.com/capricorn86/happy-dom/

@ capricorn86 Se ve bien. ¿Cumple con las especificaciones?

@ capricorn86 Se ve bien. ¿Cumple con las especificaciones?

¡Gracias @milesj!

La funcionalidad que se ha implementado se ha implementado de acuerdo con las especificaciones, pero no hay una descripción detallada de las especificaciones que se cubren todavía. Estoy pensando en agregar eso. Sin embargo, toda la funcionalidad está cubierta por pruebas unitarias.

El objetivo inicial del DOM era poder representar el lado del servidor de componentes web con buen rendimiento, ya que lo necesitaba para algunos otros proyectos.

FWIW, acabo de intentar subir nuestro proyecto de react-scripts@3 con Jest 24.9, a @react-scripts@4 con Jest 26.6.

Nuestro conjunto de pruebas de API de servidor se había estado ejecutando anteriormente en aproximadamente 180-190 segundos. Después de cambiar a Jest 26.6, tomaba constantemente alrededor de 220 segundos. Incluso intenté forzar la resolución de minimatch a 4.0.2 . Cambiar el corredor de prueba a jest-circus pareció demorar un par de segundos, pero en general, 26.6 parece notablemente más lento.

react-scripts@4 usa jest-circus por defecto, fwiw. También usamos micromatch , no minimatch . Sin embargo, parece que hemos roto el retroceso micromatch través de # 10131, por lo que ya no es tan fácil probar si esa es la causa de la regresión.

@SimenB : tenemos un convertí para compilar usando CRA . La configuración de prueba es totalmente nuestra, frente a la configuración CRA Jest incorporada; solo estamos aprovechando el hecho de que CRA viene con Jest como una dependencia.

No tengo mi caja de trabajo frente a mi cajero automático, así que ahora no puedo recordar si realmente quise decir micromatch o si realmente me concentré en el nombre de paquete incorrecto allí :) Tendré que mirar de nuevo la semana que viene.

Acabo de notar que v26 se ejecuta _mucho_ más lento en iTerm que en el terminal predeterminado de macOS. En un conjunto de 6500 pruebas, obtengo constantemente los siguientes resultados:

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

Esto me asombró un poco después de meses de probar varias cosas para solucionar la desaceleración. ¿Hay alguna posibilidad de que alguien más con problemas de rendimiento en una Mac pueda probar esto? Eso sí , esto es con

@pleunv Creo que esto puede estar relacionado: https://github.com/facebook/jest/pull/9294. Noté que los hipervínculos ralentizan iTerm2 en mi máquina, haciéndolo entrecortado. Pero no he investigado la velocidad general de ejecución, ni he encontrado a otra persona que tenga problemas.

Eureka. La búsqueda de "iTerm" me llevó a este PR . Había notado estos subrayados antes y no me di cuenta de que eran hipervínculos. Después de ver ese PR, desactivé los hipervínculos en iTerm, lo que redujo mi tiempo de ejecución a 130 s. Después de aplicar el código del PR y eliminar los hipervínculos, vuelvo a bajar a 120. Cordura levemente restaurada.

¿Alguna posibilidad de que las relaciones públicas puedan volver a entrar?

editar: @thymikee me ganó 😄

@pleunv Intentaré encontrar algo de tiempo esta semana para recuperarlo. Aunque el problema real sería arreglar esto para iTerm, ya que otros terminales, por ejemplo, en Linux, no tienen problemas con los hipervínculos. ¿Le importaría presentar un problema al proyecto iTerm?

Acabo de hacer este cambio y me dio 1 para un solo archivo de prueba. Y aún puede hacer clic en la URL, simplemente ya no está subrayada.

Esto puede ser enorme para tiradas más grandes. ❤️

//editar
Lo curioso es que antes no importaba si era iterm o terminal. Después del cambio, iterm es más rápido para mí.

@pleunv Intentaré encontrar algo de tiempo esta semana para recuperarlo. Aunque el problema real sería arreglar esto para iTerm, ya que otros terminales, por ejemplo, en Linux, no tienen problemas con los hipervínculos. ¿Le importaría presentar un problema al proyecto iTerm?

He creado un problema aquí (están en GitLab). Si alguien tiene detalles adicionales o un proyecto de reproducción, no dude en agregarlo.

Mientras tanto, estaba experimentando un poco más y descubrí que, cuando solo se ejecuta en un subconjunto más pequeño de pruebas (un par de docenas de archivos de prueba), los hipervínculos generalmente no hacen tanta diferencia. Sin embargo, cuando se ejecuta en nuestro conjunto completo (700 archivos), el impacto es muy medible.

También tengo la impresión de que, a largo plazo, la salida de la consola de broma comienza a ser realmente deslumbrante / llamativa. Las líneas de progreso en la parte inferior, por ejemplo, están más ocultas que visibles.