<p>il y a un 25 représentation</p>

Désolé pour la régression mais

désolé je ne peux pas partager notre base de code

signifie que nous ne pouvons absolument rien faire. C'est la première fois que j'entends parler d'une régression des performances, partout ailleurs j'ai entendu une amélioration de 10 à 40 % des performances passant de 24 à 25. Vous devez fournir une sorte de reproduction, sinon nous devrons clore ce problème car il n'est pas du tout exploitable en l'état.

Si vous voulez voir cela adressé, vous devrez passer un peu de temps à monter un cas de reproduction, ou espérer que quelqu'un d'autre le fera.

ok je vais voir si je peux tirer nos 10 tests les plus lents peut-être, puis essayer de les exécuter en 24 vs 25. en attendant, que recommandez-vous en ce qui concerne la suppression du cache avant d'exécuter les tests en CI ? fais le? ne le fais pas ?

Votre configuration, en particulier transforms et les fichiers d'installation sont probablement également pertinents

que recommandez-vous en ce qui concerne la suppression du cache avant d'exécuter des tests dans CI

Personnellement, je pense que c'est une bonne idée juste pour être sûr qu'il n'y a rien de périmé qui traîne en donnant de faux négatifs ou positifs. Cela fait-il une énorme différence pour l'exécution de vos tests de _pas_ vider le cache ?

il semble être un peu plus lent lorsqu'il est exécuté après avoir vidé le cache. merci pour les conseils je vais regarder ça et voir si je peux essayer une repro

FWIW, j'ai également remarqué que la v25 est soit légèrement plus lente, soit à égalité avec la v24. Je n'ai pas vu d'amélioration de près de 10 à 40 %.

J'ai vu une accélération significative par rapport à jest 24, comme indiqué ici : https://github.com/facebook/jest/issues/7811#issuecomment -577057189

Ce qui précède a été testé sur osx.

Cependant, la même configuration s'exécute beaucoup, beaucoup plus lentement sur notre CI qui exécute CentOS.

Problème spécifique à Linux ? Problèmes liés aux E/S lors de l'écriture des fichiers de cache ? Est-il possible de désactiver complètement la génération de cache pour exclure cela ?

Je pense avoir trouvé le coupable dans notre cas, c'est le drapeau --collectCoverage . Lorsqu'il est supprimé pour les Jest 24 et 25, nos tests s'exécutent à peu près deux fois plus vite sous 25. Lorsqu'il est activé, nos tests sous 25 sont presque 4 fois plus lents que les mêmes sous 24.

Ceci est reproductible à la fois sur OSX et CentOS, donc contrairement à mon commentaire précédent, le problème n'apparaît pas spécifique à Linux.

Intéressant! Nous avons mis à jour Istanbul vers la v3, peut-être que quelque chose a régressé. Nous avons ajouté la prise en charge de la couverture du code v8, donc j'ai peut-être aussi gâché la refactorisation en le faisant

Oui! C'est cohérent avec ce que je vois aussi. Nous fonctionnons avec une couverture en CI où elle est 2 fois plus lente. Et quand je cours localement sans covg, c'est assez rapide. @SimenB existe-t-il une option de configuration pour utiliser l'ancien Istanbul ? :)

Faisant écho à ce que @csvan a dit, ce serait bien de désactiver la génération de cache dans CI si c'est en fait un coupable puisque nous le supprimons de toute façon avant de construire

Je ne parviens pas à reproduire cela - les repos que je teste ont à peu près les mêmes performances avec --coverage entre v24 et v25. Quelqu'un serait-il en mesure de créer un référentiel avec jest 24 et jest 25 où le basculement entre eux montre une différence?

Je viens d'exécuter notre build CI avec la couverture désactivée, je pense que

notre exinfo de l'agent de construction :

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 

Nous assistons à un problème similaire. La mise à niveau de Jest 25 a ralenti nos tests lors de l'utilisation de la couverture (166 s avec Jest 24 contre 381 avec Jest 25). Avec Jest 25 affichant bon nombre de ces erreurs lors de l'exécution des vérifications :

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 rétrogradation à Jest 24 fait disparaître ces erreurs.

J'ai également remarqué que Jest 25 gère le collectCoverageFrom différemment car il semble collecter la couverture des fichiers que nous avons explicitement désactivés dans cette configuration. La prise en charge de la syntaxe glob a-t-elle changé là-bas ?

Des traces de JS ? Ce serait intéressant de voir où il est mort.

J'ai également remarqué que Jest 25 gère le collectCoverageFrom différemment car il semble collecter la couverture des fichiers que nous avons explicitement désactivés dans cette configuration. La prise en charge de la syntaxe glob a-t-elle changé là-bas ?

Nous sommes passés à Micromatch 4, cela a peut-être changé quelque chose. Cependant, aucun changement n'est volontairement apporté. Pourriez-vous ouvrir un problème séparé avec une reproduction?

Des traces de JS ?

Ceci a été imprimé :

==== 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 : En fait, je vois des erreurs de tas même avec la couverture désactivée.

Nous sommes passés à Micromatch 4, cela a peut-être changé quelque chose. Cependant, aucun changement n'est volontairement apporté. Pourriez-vous ouvrir un problème séparé avec une reproduction?

Ça ira.

Sonner à nouveau. La couverture est nettement plus lente et semble fausse. Voici les horaires pour 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

Horaires pour CI (travis).

v24 coverage -w 4
101.634s

v25 coverage -w 4
178.306s

@milesj c'est quoi le cirque v25 ?

C'est une plaisanterie de nouveau coureur, qui est censée être plus rapide, mais ce n'est jamais le cas d'après ce que j'ai vu. https://www.npmjs.com/package/jest-circus

@EvHaus Traces de JSDOM est intéressant (peut aussi être complètement une coïncidence, bien sûr). Pourriez-vous essayer d'installer jest-environment-jsdom@24 et de l'utiliser ? Nous sommes passés de 11 à 15, donc quelque chose a peut-être changé. On dirait un long shot, mais qui sait

@SimenB Le recul de seulement jest-environment-jsdom à <24.0.0 dans mon package.json définitivement eu un impact. Les erreurs heap out of memory ont disparu et Jest semble terminer ses courses sans aucun problème.

Intéressant! Si vous avez le temps, ce serait sympa de tester

• 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 simplement lier jsdom et diviser en deux. Je ferai ça demain, mais je n'ai pas encore vraiment de bonne reproduction

Pour les tests suivants, je n'ai pas activé la couverture.

• Avec [email protected]
  
  
  
  • 143s pour exécuter des tests
  
  
  • Pas d'issues
  
  
• Avec [email protected]
  
  
  
  • 154s pour exécuter des tests
  
  
  • Pas d'issues
  
  
• Avec [email protected]
  
  
  
  • 228 secondes pour exécuter des tests
  
  
  • 🚨Beaucoup d'erreurs JavaScript heap out of memory
  
  

Traces de pile

Voici quelques-unes des traces de la pile de l'exécution 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 

J'espère que cela t'aides

Je ne sais pas si cela va aider, mais mon organisation a connu un ralentissement massif de Jest 24 à Jest 25 (18 minutes à 28 minutes) qui a disparu après avoir désactivé la collecte de couverture (jusqu'à 10 minutes).

@rosasynstylae par curiosité, votre code a-t-il beaucoup de tests d'instantanés ?

@benmonro C'est le cas, oui.

Le nôtre aussi ! @SimenB pensez -vous que de nombreux instantanés dans un dépôt pourraient provoquer cela ?

Nous avons des problèmes de performances sans instantanés. Nous collectons une couverture cependant. Ralentissement important de 24 -> 25. 2 projets différents. Il varie mais le ralentissement est important et constant.

Je peux exécuter les tests encore et encore sans aucun changement et les tests sont en moyenne 10 fois plus lents qu'ils ne l'étaient avec 24.

Je repasse à 24 et les runs reviennent à la vitesse à laquelle nous étions habitués.

Je peux fournir plus d'informations si besoin. Je voulais m'assurer de mentionner nos 2 projets sans tests instantanés.

D'après tous les commentaires ici, il semble que la couverture soit le problème, et probablement une régression à Istanbul ?

D'après tous les commentaires ici, il semble que la couverture soit le problème, et probablement une régression à Istanbul ?

Je ne serais pas si rapide pour pointer du doigt Istanbul. Dans mon cas, même avec la couverture désactivée, je constate des problèmes de performances et de stabilité importants dans Jest 25. Voir https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Il est possible qu'il y ait deux problèmes distincts :

1) Problèmes avec jest-environment-jsdom-fourteen, et
2) Problèmes avec la couverture d'Istanbul

J'ai rétrogradé micromatch à ^3.0.0 et j'ai vu une accélération massive en utilisant --coverage , ce qui revient plus ou moins aux performances que nous avons vues sous Jest 24. Quelqu'un peut-il se reproduire ?

MISE À JOUR : Cependant, fonctionner maintenant sans --coverage revient également aux niveaux de performances Jest 24 - deux fois plus lents :-/

@EvHaus merci d'avoir vérifié, très intéressant ! Je n'arrive toujours pas à le reproduire, malheureusement. Donc, une reproduction serait toujours géniale, de cette façon, je peux essayer de déboguer cela.

J'ai rétrogradé micromatch à ^3.0.0 et j'ai vu une accélération massive en utilisant --coverage , ce qui revient plus ou moins aux performances que nous avons vues sous Jest 24. Quelqu'un peut-il se reproduire ?

MISE À JOUR : Cependant, fonctionner maintenant sans --coverage revient également aux niveaux de performances Jest 24 - deux fois plus lents :-/

Que diable... Pour autant que je puisse voir, rien à Istanbul ne dépend du micromatch, alors pourquoi cela devrait avoir un impact sur la couverture me dépasse

L'ensemble des performances du micromatch devient un peu absurde, avec une couverture v3 est plus rapide que v4, sans v4 est plus rapide que v3 ? ??

@SimenB oui ,

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

à notre package.json a économisé 6 bonnes minutes de course lors de l'utilisation de --coverage , ce qui revient à peu près à ce que nous avons vu sous Jest 24.

Pour autant que je puisse voir rien à Istanbul ne dépend du micromatch

J'ai trouvé ce commentaire dans un autre fil qui peut être lié à ceci:

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

Je viens de confirmer que rien à Istanbul n'apporte micromatch (ils utilisent minimatch dans le plugin babel).

Cela pourrait être quelque chose à propos des exclusions qui ne fonctionnent pas correctement, certainement. Nous l'utilisons pour vérifier ce que nous devons instrumenter : https://github.com/facebook/jest/blob/28f6da44cc58d41438bddfa9fcd741fd01b02ded/packages/jest-transform/src/shouldInstrument.ts. Pourriez-vous peut-être vous connecter et voir si nous retournons true n'importe où avec des micromatch@4 que nous n'avons pas pour micromatch@3 ?

Cela ressemble certainement à 2 problèmes distincts, un à propos de jsdom et un à propos de la couverture

Je peux confirmer que la vitesse est revenue à la normale pour nous en CI lorsque nous résolvons également micromatch@3 .

Jest + tapuscrit + réagir codebase ici. Voir ce problème et utiliser npm-force-resolutions pour forcer le micromatch ^3.0.0 a semblé corriger le ralentissement fou.

Avez-vous des modèles de fichiers de test personnalisés et des modèles de couverture dans votre configuration ?

@EvHaus Je suis très intéressé si vous voyez une différence en rétrogradant également Micromatch, vu que vous avez vu une grande différence avec les versions jsdom

Si c'est ce que vous voulez dire, alors oui.

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

nous avons aussi cela et le nôtre semble assez similaire en longueur/valeurs

@ Ancient123 ouais, exactement. Semble lié à la régression Micromatch pour les modèles niés. Merci!

Semble lié à la régression Micromatch pour les modèles niés. Merci!

C'est noté, je vais me renseigner au plus vite.

Toute la performance en micromatch devient un peu absurde

Désolé pour la dégradation des performances. Générer des expressions régulières pour le globbing est beaucoup plus difficile à faire qu'il n'y paraît. Surtout quand il doit gérer la négation et être multiplateforme. J'étudie ça maintenant.

@jonschlinkert, ce n'était pas du tout accusateur, le travail que vous mettez dans Micromatch et les bibliothèques associées est extrêmement apprécié ! :cœur:

Oui! ce que @SimenB a dit. rien que ❤️

@EvHaus Je suis très intéressé si vous voyez une différence en rétrogradant également Micromatch, vu que vous avez vu une grande différence avec les versions jsdom

Dans mon package.json j'ai défini :

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

Ré-exécuté npm install , puis supprimé manuellement node_modules/jest/micromatch (qui était à la version 4). Puis refait mes tests.

Malheureusement, je vois encore de nombreuses erreurs "Tas Javascript manque de mémoire".

Est-ce que je fais le downgrade correctement ?

resolutions besoin de yarn , npm ne l'a pas encore implémenté (c'est sur la feuille de route pour la v7 : https://blog.npmjs.org/post/186983646370/npm- cli-feuille de route-été-2019)

@EvHaus jusqu'à la https://www.npmjs.com/package/npm-force-resolutions

Désolé pour le retard. Utilisé npm-force-resolutions (qui fait la bonne chose) pour verrouiller micromatch à v3. Malheureusement, cela n'a pas fait disparaître mes erreurs de tas.

Donc pour moi, c'est toujours [email protected] à blâmer, comme mentionné ici : https://github.com/facebook/jest/issues/9457#issuecomment -579423330

Résoudre jsdom en thirteen est ce qui le résout.

Quelqu'un qui a subi une dégradation des performances dans 25 a-t-il des problèmes qui ne sont pas résolus en utilisant jsdom@13 ou micromatch@3 ? La fuite de mémoire dans JSDOM est en cours de correction (https://github.com/jsdom/jsdom/pull/2840 et divers problèmes/PR liés à celui-ci) et la régression en micromatch a été signalée et est en cours de traitement : https:// github.com/micromatch/micromatch/issues/179.

La version corrigée de JSDOM est sortie, vous pouvez l'utiliser en installant jest-environment-jsdom-sixteen . @EvHaus pouvez-vous vérifier que cela résout votre problème ?

@SimenB mon problème n'est probablement pas lié, mais j'ai essayé jest-environment-jsdom-sixteen rapport à l'utilisation de la valeur par défaut, et j'ai constaté une augmentation de 20 secondes de la durée d'exécution pour la même suite de tests au cours d'exécutions répétées.

sur l'utilisation de la v15 (qui est livrée avec jest par défaut) et aucun autre changement ? Pourriez-vous également tester avec 16.1.0 (bien que cela perde de la mémoire, cela pourrait donc être plus difficile à tester). JSDOM vient d'atterrir avec la prise en charge des éléments personnalisés, il pourrait y avoir une régression là-dedans ? Pas certain

La version corrigée de JSDOM a été publiée, vous pouvez l'utiliser en installant jest-environment-jsdom-sixteen. @EvHaus pouvez-vous vérifier que cela résout votre problème ?

Malheureusement, toujours des erreurs de tas avec jest-environment-jsdom-sixteen . La dernière version de travail stable de JSDom pour moi est jest-environment-jsdom-thirteen .

La version corrigée de JSDOM est sortie, vous pouvez l'utiliser en installant jest-environment-jsdom-sixteen . @EvHaus pouvez-vous vérifier que cela résout votre problème ?

L'environnement fonctionne avec notre base de code, mais nous constatons toujours une régression de près de 100 % au moment de l'exécution. Pour l'anecdote, jest-environment-jsdom-sixteen semble améliorer les performances de temps d'exécution de 10 % seulement lors de l'utilisation de 25.1 vs 24.9

Salut @SimenB ,

J'ai fait le cas reproductible ici https://github.com/olebedev/jest-perf-issue. S'il vous plaît, jetez un oeil. Ci-dessous le résultat à comparer. /cc @joscha

Résultats

Les benchmarks ont été exécutés sur MBP 2019, 32Gb RAM, i9-8950HK CPU @ 2.90GHz .

| version plaisante | succursale | temps |
|:--------------|:------:|----------:|
| 24.9.0 | master | 348.077s |
| 25.1.0 | jest25 | 591.33s |

Dans notre cas, où jest v25.1 était ~ 50% plus lent par rapport à v24.9, maintenant le dernier jest v25.2.0 est encore 20% plus lent par rapport à v25.1 🙈

@olebedev Woah, c'est douloureux 😬

Je reçois des chiffres similaires à vous. Si c'est basé sur un projet réel, je recommande d'utiliser la couverture v8. Cela prend le temps d'exécution de 600s à 35s sur ma machine dans votre reproduction. La raison de l'énorme différence est probablement que nous n'essayons pas d'instrumenter les fichiers non couverts avec une couverture v8 (nous disons simplement que chaque octet est découvert, ce qui fonctionne avec la v8).

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

Je ne sais pas pourquoi c'est si lent... Je vais essayer de trouver un peu de temps pour m'y pencher (ce ne sera pas de sitôt cependant). Il ne devrait au moins pas être plus lent sur la v25 que sur la v24

Est-ce que je comprends bien les documents que nous pouvons utiliser la couverture v8 ensemble
avec l'environnement ...-sixteen ?

Acclamations,
J

Le mer. 8 avril 2020, 22:33 Simen Bekkhus, [email protected] a écrit :

@olebedev https://github.com/olebedev Woah, ça fait mal 😬

Je reçois des chiffres similaires à vous. Si c'est basé sur un vrai projet, je
recommande d'utiliser la couverture v8. Cela prend le temps d'exécution de 600s à 35s sur mon
machine dans votre reproduction. La raison de l'énorme différence est probablement que
nous n'essayons pas d'instrumenter les fichiers non couverts avec une couverture v8.

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

Je ne sais pas pourquoi c'est si lent... Je vais essayer de trouver un peu de temps pour m'en occuper.
Il ne devrait au moins pas être plus lent sur la v25 que sur la v24

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/facebook/jest/issues/9457#issuecomment-610931770 , ou
Se désabonner
https://github.com/notifications/unsubscribe-auth/AABN5BW6R45SS5Z5GXGFGF3RLRVJLANCNFSM4KK67LOA
.

Oui, soit jest-environment-jsdom-sixteen , soit le pack jest-environment-node . Notez également qu'il n'est pris en charge que sur le nœud 10+, pas sur le nœud 8.

(Je n'ai jamais testé cela qu'avec l'env Node, mais si cela ne fonctionne pas avec l'env jsdom, c'est un bug - veuillez ouvrir un problème séparé )

jest-environment-jsdom-sixteen + v8 en tant que fournisseur de couverture était pire d'environ 20% pour nous sur jest 25.3.0, nœud 12.16. Nous essayons également de déboguer pourquoi nos performances de test se sont détériorées d'environ 80%, passant de 24 à 25.

@joual avez-vous essayé la solution de contournement du micromatch (rétrogradation à 3.x) ?

Ayant une expérience similaire ici, les temps de test (_sans_ couverture) doublent sur la v25 de 35-40 secondes à 80-90 et parfois plus. J'ai essayé de verrouiller le micromatch sur v3, aucune différence mesurable. Fwiw, nous avons environ 3k tests dont 58 sont des tests instantanés.
Tentative de rétrogradation de jsdom, mais cela semble introduire de nombreuses pannes de test en raison des fonctionnalités récentes que nous avons utilisées. Je vais voir si je peux contourner ça d'une manière ou d'une autre et faire rapport.

@SimenB Le travail de collecte de couverture sur un plus joli projet est également très lent, pouvez-vous le vérifier? https://github.com/prettier/prettier/runs/579497097 Node.js 12 on ubuntu-latest collecte la couverture, les autres travaux ne le font pas.

Ayant une expérience similaire ici, les temps de test (_sans_ couverture) doublent sur la v25 de 35-40 secondes à 80-90 et parfois plus. J'ai essayé de verrouiller le micromatch sur v3, aucune différence mesurable. Fwiw, nous avons environ 3k tests dont 58 sont des tests instantanés.
Tentative de rétrogradation de jsdom, mais cela semble introduire de nombreuses pannes de test en raison des fonctionnalités récentes que nous avons utilisées. Je vais voir si je peux contourner ça d'une manière ou d'une autre et faire rapport.

J'expérimentais différentes versions de jsdom aujourd'hui sur jest@24 (qui est la v11 par défaut). Jusqu'à la v14, tout semble bien fonctionner, mais à partir de la v15, les tests prennent toujours 50 à 60 % plus de temps. Même histoire en v16. Je vais voir si je peux obtenir des performances similaires sur jest@25 en rétrogradant jsdom en v14.

[email protected] a quelques correctifs de mémoire, @EvHaus pourriez-vous l'essayer ? Le propre --detect-leaks Jest trouve des fuites dans les versions précédentes, mais pas dans 16.2.2.

J'ai également obtenu d'autres améliorations si vous avez beaucoup de liens symboliques (ce qui est très lent sous Windows), donc si les gens pouvaient essayer [email protected], ce serait sympa 🙂

@SimenB Quel est le moyen le plus simple de tester cela ? Si j'ajoute [email protected] directement en tant que devDependency, Jest l'ignore et utilise tout ce qui est fourni avec jest-environment-jsdom qui est 15.2.1 aujourd'hui.

Comment puis-je tromper npm pour m'assurer qu'il utilise la version jsdom que je veux ?

Installez jest-environment-jsdom-sixteen et utilisez-le https://jestjs.io/docs/en/configuration#testenvironment -string

Alpha publié, vous pouvez donc essayer jest@next - il est livré avec jsdom 16 prêt à l'emploi

@SimenB Désolé, pas beaucoup de chance avec [email protected] et ses [email protected] . Vous obtenez toujours beaucoup de ces erreurs :

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

Et finalement le coureur meurt.

Mes Details:

> 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 

Voici quelques-unes des piles complètes renvoyées par celles-ci :

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

Dommage 😞 C'est avec ou sans couverture ?

C'était sans couverture. Aurait dû préciser.

Pensez-vous que j'utilise une version assez ancienne de Node (v10) en serait-il un facteur ?

Vous pouvez essayer d'utiliser des versions plus récentes, à tout le moins ce serait un point de données intéressant. D'autres choses à essayer sont d'essayer de faire un vidage de tas juste avant qu'il ne meure. Qu'est-ce qu'il y a sur le tas ?

Il est intéressant de noter que personne n'a mentionné que micromatch@4 ne met plus en cache les expressions régulières (voir https://github.com/micromatch/micromatch/pull/151 et https://github.com/facebook/jest/pull/10131 introduit manquant mise en cache du côté de la plaisanterie.

Pour moi, rétrogradez à micromatch@3 et jest-environment-jsdom-sixteen économisant 50 % de temps.
Mais avec jest 26 et jsdom intégré, j'obtiens toujours une erreur de fuite lorsque j'exécute jest avec --detectLeaks dans mon cas. J'ai essayé un nouveau dépôt et tout fonctionne bien.

https://github.com/facebook/jest/pull/10131 est fusionné !! <3

Sorti en 26.1.0, très intéressé à savoir si cela aide les gens

@SimenB merci beaucoup pour la sortie ! malheureusement de notre côté nous sommes toujours confrontés à une énorme différence :

courant:

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

sur chaque version supérieure à 24.9

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

à la fois avec de nouveaux caches et après une réinstallation complète de tous les modules de nœud. configurations intactes.
exécuter des tests en mode montre, il faut plus de 3 minutes sur ma machine pour déterminer quels tests exécuter. Je ne peux pas vraiment isoler le problème pour une reproduction mais si vous me donnez des conseils sur ce que je dois tester, je serais très intéressé. merci pour tout le travail que vous fournissez!

@SimenB

Pour le projet prettier , toujours plus lent que v24 lors de la collecte de la couverture.

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

Je peux confirmer que les performances des versions 25 et 26 sont inférieures à celles de la 24 sur Bitbucket Pipeline. J'ai également remarqué que la lenteur augmente avec la couverture activée. La version 25 est encore pire par rapport à la 26 et le pipeline plante à cause de la consommation de mémoire.

@SimenB J'ai fait un git bisect pour savoir où la régression des performances entre 24,9 et 25,1 a été introduite. J'ai utilisé les tests les plus jolis car ils s'exécutent sans modification de 24,9 à 26,1.

J'ai comparé le temps d'exécution cumulé de trois exécutions du sous-ensemble js (pour sécuriser un certain temps) avec le cache désactivé. Plus spécialement, la commande que j'utilise était ( yarn run jest --no-cache tests/js/ ) avec le nœud 10.19. car le nœud 10 était la version recommandée pour le 24.9.

Résultats:

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)

Puisqu'il y a une solution de repli si compileFunction n'est pas défini, j'ai supprimé la branche compileFunction de ad5377333daf6716af3465bba39f86b7db485e2b qui a restauré les performances.

En regardant 26.1, le code a un peu bougé mais compileFunction et le repli sont toujours là. Alors:

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

c'est-à-dire que la suppression de la branche compileFunction ( patch ) ramène 26.1 à l'exécution de 24.9. Je suis sûr que ce n'est pas la solution, mais au moins nous avons quelque chose avec quoi travailler.

Comme autre point de données, notre suite de jest prend actuellement environ 2767 secondes avec [email protected] et dans notre mise à jour MR, cela prend environ 3497 secondes, soit une augmentation d'environ 27%.

Merci pour tout l'excellent travail, équipe de plaisanterie, j'espère que les compétences de détective de @wurstbonbon pourront vous aider à corriger cette régression !

@wurstbonbon merci d'avoir pris le temps de creuser ! Très intéressant que compileFunction soit plus lent... Cela devrait signifier que vous pouvez simplement utiliser un environnement de test personnalisé au lieu d'appliquer un correctif.

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

class MyNodeEnv extends NodeEnv {}

delete MyNodeEnv.prototype.compileFunction;

module.exports = MyNodeEnv;

(et pareil pour jsdom env). Pouvez-vous confirmer?

Le fait qu'il s'agisse d'un tel goulot d'étranglement semble cependant étrange - Node lui-même est passé à l'utiliser il y a 18 mois : https://github.com/nodejs/node/pull/21573. C'est donc probablement quelque chose de bizarre que nous faisons de notre côté. Le lien https://github.com/nodejs/node/issues/26229 est cependant très intéressant - peut-être devons-nous faire un peu plus de mise en cache de notre côté ?

@SimenB, je viens d'essayer quelque chose de similaire à cet

J'ai dû faire MyNodeEnv.prototype.getVmContext = null; , car je teste avec jest 26, et il semble qu'il vérifie if (typeof this._environment.getVmContext === 'function') { maintenant . Je ne sais pas si cela pourrait causer d'autres problèmes, cependant.

Voici les résultats que je vois après quelques essais :

Jest 26 avec environnement de test : "node" => ~280 s
Jest 26 avec environnement de test personnalisé => ~210s
Jest 24 => ~160s

Faites-moi savoir si je peux vous aider avec d'autres informations ou autre chose !

Comme prévu, l'environnement personnalisé entraîne la même accélération pour le plus joli.

Je l'ai également essayé sur notre base de code où la différence est d'environ 270 s contre environ 200 s, donc seulement environ 25 % et non 40 % de réduction. Malheureusement, je ne peux pas exécuter nos tests avec jest 24 car nous nous appuyons sur les nouveaux timers modernes moqueurs.

J'ai raté un delete dans mon exemple ci-dessus, désolé pour ça.

Je me demande s'il suffit de mettre en cache les fonctions compilées manuellement - pourriez-vous essayer d'appliquer ce correctif ? (les deux JS transpilés et la source TS sont inclus ici)

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

J'ai pensé que cela pourrait faire l'affaire.

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

Cela améliore un peu les performances mais Script est toujours beaucoup plus rapide.

J'ai essayé la recommandation de https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252/diffs?commit_id=6d633c88caf70f712fa0ccaac42d952976161ec6

Bien qu'il ait un peu amélioré les performances, il est toujours considérablement plus lent que sur jest 24.x :

• Jest 24.x : 2580 secondes d'exécution totale de nos tests de jest
• Jest 26.x : 3166 secondes d'exécution totale de nos tests de jest

@leipert Avez-vous par hasard essayé de rétrograder l'environnement jsdom à 14 ?

yarn add test-environment-jsdom-fourteen --dev + "testEnvironment": "test-environment-jsdom-fourteen" dans votre configuration de plaisanterie. Cela semble toujours être responsable de la majeure partie de l'augmentation de la durée pour nous (ajoute 40 à 50 %) mais cela commence à ressembler à de multiples régressions en jeu.

@pleunv Avec jest 24.x, nous sommes sur jsdom 16 avec jest-environment-jsdom-sixteen , nous avons dû mettre à niveau en raison de problèmes de test des composants Web. Donc le seul changement que nous faisons : jest 24.x + jest-environment-jsdom-sixteen -> jest.26x + jest-environment-jsdom , donc la version jsdom ne change même pas.

Ouvert https://github.com/nodejs/node/issues/35375 en amont sur le problème trouvé par @wurstbonbon

@SimenB connaissez-vous des alternatives viables au micromatch ? Ce dépôt est silencieux depuis plus de six mois maintenant, et des problèmes majeurs affectant Jest comme https://github.com/micromatch/micromatch/issues/179 sont toujours ouverts.

Pas vraiment, c'est ce que la plupart des bibliothèques utilisent. Pourrait regarder par exemple minimatch, mais je doute que ce soit viable

@SimenB Qu'est-ce qui rend le micromatch meilleur que toutes les alternatives ?

Sur la base des commentaires dans le problème que j'ai ouvert, je pense que nous devrions revenir à l'utilisation de Script pour le moment car il semble qu'il faudra un peu de travail dans Node pour y remédier.

@leipert @wurstbonbon ou quelqu'un d'autre, pouvez-vous essayer ce patch dans votre 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) {

J'ai testé le patch pour utiliser Script sur nos suites de test et voici le résultat auquel je suis arrivé
L'heure est en min:sec

Nom | Suite 1 | Suite 2 | Suite 3 | Suite 4
-- | -- | -- | -- | --
plaisanterie 24 | 3:25 | 15h30 | 3:29 | 0:53
jest 26 patché | 3:32 | 4:36 | 3:48 | 0:53
plaisanterie 26 non corrigée | 5:10 | 6:12 | 5:11 | 1:07
26 patchés contre 24 | 4% | 31% | 9% | 1%
26 non corrigés contre 24 | 52% | 76% | 49% | 27%
26 patchés vs non patchés | 46% | 35% | 36% | 25%

toujours intéressant que la v26 ne s'améliore toujours pas par rapport à la v24...

Merci @Cellule ! C'est assez bon pour moi - je préparerai un PR quand j'aurai un peu de temps

Des trucs géniaux ! Cela ne laisse alors que le problème de Micromatch, avec un peu de chance, ce repo fera à nouveau l'objet d'une maintenance active.

BTW, il y a aussi une régression perf dans JSDOM, je suppose. Comme j'ai fait de tels tests sur un gros projet web. Aucun correctif mentionné ci-dessus n'est appliqué.
Et ça ressemblait à ça.

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)

C'est sûrement un rapport de performance super vague et instable que je dois rester, mais je pense que chaque entrée aide :)

https://github.com/facebook/jest/releases/tag/v26.5.0 a le changement vm.Script discuté ici

(Edit : mis à jour après des exécutions supplémentaires)

Résultats préliminaires sur la même suite de tests :

Blague 26,5
Froid : 59,992
Chaud : 43,976

Jest 26.4 :
Froid : 90.213
Chaud : 47.408

Une accélération très importante à froid <3

Et voici les résultats avec ma suite de tests :

Blague 26,5
Froid : 149s

Blague 26,4
Froid : 226s

Bonne nouvelle 🙂 Je pense que nous sommes de retour à la régression du micromatch, alors

Si vous utilisez npm-force-resolutions pour installer de force Micromatch 3. Cela peut ne pas fonctionner dans [email protected]

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

Erreur lors de l'exécution du test :

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 Merci beaucoup pour la mise à jour. Cela nous fait gagner 20% de temps d'exécution sur Travis après la mise à jour vers [email protected]

Nos résultats :

C'est la v26.5

• 323.98s
• 321.24s

C'est la v24.9

• 262.17s
• 275.96s

Merci @SimenB ! Ceci est incroyable. Nos résultats pour nos ~22000 tests dans ~2000 suites :

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

ce qui est environ 3% plus lent et donc dans la marge d'erreur, par rapport au ralentissement d'environ 27% que nous avons vu auparavant. Merci, il ne nous reste plus qu'à fusionner : https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33252#note_425616404

Je voulais juste noter que tous les problèmes de « manque de mémoire » que j'avais auparavant ont disparu après la mise à niveau vers Jest 26.5.2 et le nœud 14 (c'était auparavant sur le nœud 10). Je ne sais pas dans quelle mesure le problème a été causé par Jest par rapport à Node, mais si d'autres rencontrent des problèmes similaires, essayez de passer aux deux.

MISE À JOUR : Qu'à cela ne tienne. J'ai recommencé à avoir des erreurs OOM. Je suppose que c'est juste à la limite de ce que mon ordinateur portable peut gérer et que les premières courses étaient bonnes, mais maintenant, il meurt à nouveau. Devra toujours s'en tenir à 24.xx :(

Si quelqu'un est intéressé, j'ai créé un DOM qui a de très bonnes performances par rapport à JSDOM. Il a un support pour Jest.

| Opération | JSDOM | Joyeux DOM |
| ------------------------------------ | ------- | --------- |
| Importer / Exiger | 333 ms | 45 ms |
| Analyser HTML | 256 ms | 26 ms |
| Sérialiser HTML | 65 ms | 8 ms |
| Rendu élément personnalisé | 214 ms | 19 ms |
| querySelectorAll('tagname') | 4,9 ms | 0,7 ms |
| querySelectorAll('.class') | 6,4 ms | 3,7 ms |
| querySelectorAll('[attribut]') | 4,0 ms | 1,7 milliseconde |
| querySelectorAll('[class~="nom"]') | 5,5 ms | 2,9 ms |
| querySelectorAll(':nth-child(2n+1)') | 10,4 ms | 3,8 ms |

Lien vers le projet :
https://github.com/capricorn86/happy-dom/

@ capricorne86 Ça a l' air sympa. Est-ce conforme aux spécifications ?

@ capricorne86 Ça a l' air sympa. Est-ce conforme aux spécifications ?

Merci @milesj !

La fonctionnalité qui a été implémentée a été implémentée conformément aux spécifications, mais il n'y a pas encore d'aperçu détaillé des spécifications couvertes. Je pense à l'ajouter. Cependant, toutes les fonctionnalités sont couvertes par des tests unitaires.

L'objectif initial du DOM était de pouvoir rendre les composants Web côté serveur avec de bonnes performances, car j'en avais besoin pour d'autres projets.

FWIW, je viens d'essayer de faire passer notre projet de react-scripts@3 avec Jest 24.9 à @react-scripts@4 avec Jest 26.6.

Notre suite de tests d'API de serveur s'exécutait auparavant en 180 à 190 secondes environ. Après être passé à Jest 26.6, cela prenait systématiquement environ 220 secondes. J'ai même essayé de forcer la résolution de minimatch à 4.0.2 . Le passage du lanceur de test à jest-circus semblé faire tomber quelques secondes, mais dans l'ensemble, 26.6 semble sensiblement plus lent.

react-scripts@4 utilise jest-circus par défaut, fwiw. C'est aussi micromatch nous utilisons, pas minimatch . Il semble que nous ayons interrompu l'annulation de micromatch via #10131, cependant, il n'est donc plus aussi facile de tester si c'est la cause de la régression

@SimenB : nous avons un j'ai convertie pour créer à l'aide de CRA . La configuration de test est la nôtre, par rapport à la configuration CRA Jest intégrée - nous profitons simplement du fait que CRA est livré avec Jest en tant que dépendance.

Je n'ai pas ma boîte de travail devant moi au guichet automatique, donc maintenant je ne me souviens plus si je voulais vraiment dire micromatch ou si je me suis vraiment concentré sur le mauvais nom de paquet là :) Je vais devoir regarder à nouveau la semaine prochaine.

Je viens de remarquer que la v26 s'exécute _beaucoup_ plus lentement dans iTerm que dans le terminal par défaut de macOS. Sur un ensemble de 6500 tests, j'obtiens systématiquement les résultats suivants :

• v24, terminal : ~90s
• v24, iTerm2 : environ 90 s
• v26, terminal : ~110s
• v26, iTerm2 : ~150 s

Cela m'a un peu époustouflé après des mois d'essais de diverses choses pour régler le ralentissement. Y a-t-il une chance que quelqu'un d'autre ayant des problèmes de performances sur un mac puisse essayer cela? Remarquez , c'est avec

@pleunv Je pense que cela peut être lié : https://github.com/facebook/jest/pull/9294. J'ai remarqué que les liens hypertexte ralentissaient iTerm2 sur ma machine, le rendant instable. Mais je n'ai pas enquêté sur la vitesse globale d'exécution, ni trouvé une autre personne qui avait des problèmes avec cela.

Eurêka. La recherche de "iTerm" m'a amené à ce PR . J'avais remarqué ces soulignements auparavant et je n'avais pas réalisé qu'il s'agissait d'hyperliens. Après avoir vu ce PR, j'ai désactivé les liens hypertexte dans iTerm, ce qui a ramené mon temps d'exécution à 130 s. Après avoir appliqué le code du PR et supprimé les hyperliens, je reviens à 120s. Hygiène légèrement restaurée.

Y a-t-il une chance que les relations publiques soient remises en place ?

edit: @thymikee m'a devancé 😄

@pleunv Je vais essayer de trouver du temps cette semaine pour le ramener. Bien que la vraie affaire soit de résoudre ce problème pour iTerm, car d'autres terminaux, par exemple sous Linux, n'ont aucun problème avec les hyperliens. Cela vous dérangerait-il de déposer un problème pour le projet iTerm ?

Je viens de faire cette modification et cela m'a donné 1 pour un seul fichier de test. Et vous pouvez toujours cliquer sur l'url, elle n'est tout simplement plus soulignée.

Cela peut être énorme pour les grandes courses. ️

//Éditer
Chose amusante, cela ne faisait aucune différence avant si c'était iterm ou terminal. Après le changement, iterm est plus rapide pour moi.

@pleunv Je vais essayer de trouver du temps cette semaine pour le ramener. Bien que la vraie affaire soit de résoudre ce problème pour iTerm, car d'autres terminaux, par exemple sous Linux, n'ont aucun problème avec les hyperliens. Cela vous dérangerait-il de déposer un problème pour le projet iTerm ?

J'ai créé un problème ici (ils sont sur GitLab). Si quelqu'un a des détails supplémentaires ou un projet de repro, n'hésitez pas à en ajouter.

J'expérimentais un peu plus entre-temps et j'ai découvert que, lorsque je ne l'exécutais que sur un plus petit sous-ensemble de tests (quelques dizaines de fichiers de test), les liens hypertexte ne faisaient généralement pas une grande différence. Cependant, lorsque vous l'exécutez sur notre ensemble complet (700 fichiers), l'impact est très mesurable.

J'ai aussi l'impression qu'à long terme, la sortie console d'une blague commence à devenir vraiment glitch/flashy. Les lignes de progression en bas par exemple sont plus cachées que visibles.