Jest: Jest est 3 fois plus lent sur toutes les machines Windows (Windows 10 et inférieur)

Connexes: # 6783

Le démarrage est-il lent ou également en mode montre? Si juste au démarrage, vous pouvez essayer d'installer watchman , cela devrait aider (https://facebook.github.io/watchman/docs/install.html)

Quand il passe par les tests, cela semble bien à partir de là (EDIT: En fait, il est également plus lent lors de l'exécution des tests. Il passe un par un à la vitesse de 0,5 seconde alors que la norme est de 0,05
s par test)
Cependant, il est lent au démarrage et / ou au lancement des tests de plaisanterie (délai d'environ 4 à 6 secondes, 4 à 6 fois plus lent que les machines mac)

J'essaierai le gardien et je te recontacterai

Si vous pouviez profiler en utilisant par exemple ndb le démarrage et comprendre ce qui est lent, ce serait également d'une grande aide 🙂

Le délai est encore lent même avec le gardien installé.
J'ai exécuté un test de profilage avec ndb en cours d'exécution "jest --verbose", voici les résultats:

Capture d'écran des 1,7 premières secondes:

Capture d'écran de 1,8 à 2,7 secondes

Un fichier .json et un fichier .heapsnapshot enregistrés à partir de l'onglet de profil dans ndb après l'enregistrement:

profiling.zip

@pfftdammitchris quel est votre cas d'utilisation [exact] où vous avez remarqué la lenteur?
(un fichier ou plusieurs fichiers)? (mode montre ou non)? pouvez-vous donner l'exemple.
pour un problème de mode de surveillance de fichier => veuillez lire mon dernier commentaire dans: # 6783

Il est lent pour les fichiers simples et multiples, avec ou sans mode montre. À peu près chaque fois qu'il exécute un test, il y a un délai de 3 secondes et plus pour l'initialisation des tests, et il est lent d'exécuter les tests un par un de 0,3 ou 0,4 ou 0,5 seconde chacun alors que les autres exécuteurs de test comme mocha / chai s'exécuteraient généralement chacun comme si cela ressemblait à 0,05 seconde chacun.

J'utilise jest dans codesandbox et ils semblent lancer instantanément jest sur les tests d'initialisation / en cours d'exécution, j'ai regardé mes collègues exécuter jest sur leurs machines mac et ils l'exécutent instantanément comme normalement. Ce ne sont que des machines Windows pour autant que je sache. J'utilise une machine Windows au travail et la plaisanterie a le problème de lenteur là-bas, et j'utilise également une machine Windows à la maison et le problème continue ici.

J'ai utilisé --runInBand mais cela semblait avoir légèrement ralenti les tests unitaires encore plus de 0,2 seconde supplémentaire chacun, en fonction du ressenti.

Clarification

J'ai utilisé --runInBand mais cela semblait avoir légèrement ralenti les tests unitaires encore plus de 0,2 seconde supplémentaire chacun, en fonction du ressenti.

=> avez-vous essayé avec la v24? de la v23 à la v24, vous verrez une bonne amélioration pour ce scénario UNIQUEMENT:
_sur le rerun avec watch et uniquement si vous exécutez sur un seul fichier (pas lors de la première exécution) _
-> 2 / 3sec baisse à 0.4 / 0.5sec.
mais comparé à mac je n'ai jamais essayé ... alors peut-être que c'est toujours mauvais ... même avec l'amélioration actuelle

@SimenB

1. Je considère https://github.com/facebook/jest/issues/7110 comme des régressions de vitesse Jest [v22 vs v23] sur Windows pour TOUS les scénarios problématiques.
   où # 6783 est l'un d'entre eux

2. Je peux considérer ce problème comme: problème de vitesse pour la plaisanterie [Mac vs Windows] pour TOUS les scénarios problématiques.

Bonjour à tous !
Je cumule la lenteur de jest 24 et windows 10 (800s pour 400 tests!). Le moyen le plus rapide que j'ai trouvé pour accélérer tout cela est d'utiliser wsl au lieu de powershell ou cmd. Maintenant, mes tests ne prennent "que" 189s.

Nous avons une suite de 144 fichiers de tests avec 1302 tests qui prennent 1 minute et 43 secondes pour s'exécuter sur une machine Windows 10 build 15063, Core i7 avec 16 Go, et ils prennent 28 secondes sur un MAC OS Mojave avec 32 Go. Notre équipe de développement est répartie uniformément entre Windows et Mac et les chiffres sont très reproductibles.

Voici un test simple -

it("works", () => {
  expect(1).toEqual(1);
});

Je l'ai mis dans codesandbox et il fonctionne à peu près instantanément - https://codesandbox.io/s/4q8l0q52lw

sur ma machine Windows même si cela prend 4-5 secondes -

PASS src / index.test.js
v fonctionne (62ms)

Suites de tests: 1 réussie, 1 au total
Tests: 1 réussi, 1 au total
Instantanés: 0 au total
Temps: 4.158s
Ran toutes les suites de tests.

Le test lui-même a duré 62 ms, mais le reste du faisceau de test a pris 4 secondes. Réexécuter le test en appuyant sur Entrée, cela prend le même temps.

Mes paramètres -

> npx envinfo --preset jest

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD

Je l'ai essayé avec le WSL Ubuntu et j'ai obtenu les mêmes résultats (4-5 secondes) - ces paramètres -

  System:
    OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm

Je ne fais que commencer avec Jest, alors faites des tests assez simples, et ils peuvent prendre 15 à 20 secondes pour s'exécuter. J'adorerais les faire fonctionner rapidement - sinon, j'ai tendance à perdre le fil de mes pensées!

@bburns lire le problème ci-dessus

@kensherman
pouvez-vous essayer avec micromatch 4 dans vos résolutions de fil. pour voir si c'est mieux dans Windows s'il vous plaît?
https://github.com/facebook/jest/issues/7963#issuecomment -483985345

Je suis sur un tout nouveau MacBook Pro. Comme j'ai des étudiants sur MacOS et Windows 10, j'ai décidé d'ajouter deux partitions supplémentaires à mon disque; un pour Windows 10 et un pour le stockage partagé utilisant Tuxera NTFS.

J'ai rencontré ce problème de vitesse aujourd'hui en préparant une leçon JavaScript qui incorpore des tests unitaires. J'exécute en fait Jest à partir de MacOS mais le code et les tests sont situés sur la partition NTFS partagée. Même avec toutes les suites marquées comme describe.skip , Jest prend plus de 10 secondes pour se terminer, à la fois en mode single-run et watch.

8 suites
42 tests

J'ai échangé jest contre mocha et chai et les courses sont revenues à environ 1 seconde en mode veille simple et 10 millisecondes.

J'ai troqué la plaisanterie pour le moka et le chai et les courses sont revenues à environ 1 seconde en mode montre simple et 10 millisecondes.

En gros, vous n'avez pas lu mon dernier message. Vous vouliez promouvoir mocha/chai ... nous le savons tous ... Nous essayons de corriger la régression de la plaisanterie. Soit vous aidez à faire cela [à partir de mon message] ...can you try with micromatch 4... soit vous gardez ces commentaires inutiles hors du fil de discussion. Désolé d'être direct, mais à un moment donné, il n'y a pas d'autre moyen de le dire.

@nasreddineskandrani J'essaie [email protected] mais je peux toujours voir une exécution extrêmement lente lors de l'exécution en mode montre, toute aide serait très appréciée.

@pachumon le correctif n'est pas présent dans 24.8.0 pour autant que je sache

vous devez définir une dépendance de jest sur une version spécifique pour supprimer le problème de performances (théoriquement) le correctif sera par défaut présent dans jest 25 => lisez ici pour savoir comment un développeur le découvre https://github.com/ facebook / jest / issues / 7963 # issuecomment -483985345

pour définir la dépendance (micromatch) sur la version où le correctif a été fait => vous pouvez vérifier ici j'ai fait un exemple dans un petit projet
https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

Ajoutez à votre package.json : (doit utiliser yarn non npm )

...
  "resolutions": {
    "micromatch": "^4.0.0"
  }
...

J'espère que cela t'aides! et en attente de commentaires

La durée de mon test est également passée de ~ 2,5 minutes sur 23.6.0 à ~ 15 minutes sur 24.7.1 et 24.8.0. Notre serveur CI exécute Windows et a connu une augmentation similaire du temps de construction avec cette mise à niveau. J'ai essayé le remplacement de la résolution de la dépendance micromatch comme mentionné ci-dessus par @nasreddineskandrani en vain. Veuillez me faire savoir si je peux faire quelque chose pour vous aider à diagnostiquer ce problème.

@TomMahle c'est un super mauvais newz :( (la régression dont nous parlons en haut était déjà en 23.6)
À l'heure actuelle, un simple projet «échantillon» a montré de bonnes performances. après la mise à jour micromatch.
donc nous avons besoin d'un vrai projet problématique à déboguer, votre projet est privé? ou public?

Merci pour la suggestion à propos de micromatch @nasreddineskandrani , mais comme @TomMahle ci-dessus, l'épingler à ^4.0.0 ne semble pas non plus améliorer les performances pour moi. 😢

J'ai découvert une chose géniale, cependant, qui pourrait aider à diagnostiquer ce problème.

J'ai la possibilité d'exécuter jest soit sur mon système Windows natif, dans un conteneur Docker avec le répertoire principal de l'application monté à partir de mon système de fichiers Windows. L'exécution en mode non-surveillance semble avoir un comportement presque identique dans les deux systèmes, ce qui suggère peut-être, comme @thebearingedge l' impliquait, que le problème principal a quelque chose à voir avec le système de fichiers NTFS, puisque mon conteneur docker exécute finalement tout sauf le système de fichiers dans une machine virtuelle Linux.

Cependant, en mode veille, les choses sont légèrement différentes: les fenêtres natives fonctionnent toujours lentement comme prévu, mais le conteneur Docker n'exécute les tests que lentement lors de la première exécution . Une fois que je lui ai dit d'exécuter n'importe quelle suite de tests pour la deuxième fois (par exemple en appuyant sur p et en entrant un modèle), il exécute les tests en moins d'une seconde (faire la même chose dans les fenêtres natives prend 3-4 secondes). Le seul inconvénient de l'utilisation de docker est que les événements de changement de fichier ne semblent pas se propager de mon volume Windows à docker, je dois donc appuyer manuellement sur Entrée pour réexécuter le test plutôt que de le faire faire automatiquement, mais je suppose que c'est sans rapport avec le problème en question.

@nasreddineskandrani. Malheureusement, mon projet est privé. S'il y a des échantillons de code plus petits (la configuration de plaisanterie?) Ou des statistiques que je pourrais fournir, je suis heureux de le faire, cependant. Tous les tests semblent être considérablement plus lents (uniquement sur Windows), donc je ne pense pas que cela ait à voir avec les tests spécifiques.

Je termine un travail de docker que je fais pour mes sites Web personnels -> après (dans une semaine) je reviendrai là-dessus.

@TomMahle
Je vais essayer de mon côté d'avoir un github repo avec le problème que vous décrivez.

1. Combien de tests avez-vous?
2. activez-vous le mode dom pour les tests?
3. c'est réagir ou anguleux?
   prime:
4. pouvez-vous essayer de reproduire le problème dans un dépôt github pour pouvoir déboguer?
   vous pouvez bifurquer le mien: https://github.com/nasreddineskandrani/benchmark_jest
   Ou
5. peut-être essayer mon repo sur votre machine de test? et voir les résultats? entre 23,6 et 24

Je pensais que suffisamment d'attention avait été accordée aux mainteneurs de micromatch pour que cela ait déjà dû être réglé. Exécuter (donc écrire) des tests de plaisanterie sur Windows est une expérience très désagréable pour le moment.

Je suis passé au moka / chai depuis lors, mais je suis surpris que ce problème soit toujours en cours d'élaboration.

Clarification

J'ai utilisé --runInBand mais cela semblait avoir légèrement ralenti les tests unitaires encore plus de 0,2 seconde supplémentaire chacun, en fonction du ressenti.

=> avez-vous essayé avec la v24? de la v23 à la v24, vous verrez une bonne amélioration pour ce scénario UNIQUEMENT:
_sur le rerun avec watch et uniquement si vous exécutez sur un seul fichier (pas lors de la première exécution) _
-> 2 / 3sec baisse à 0.4 / 0.5sec.
mais comparé à mac je n'ai jamais essayé ... alors peut-être que c'est toujours mauvais ... même avec l'amélioration actuelle

@SimenB

1. Je considère # 7110 comme des régressions de vitesse Jest [v22 vs v23] sur Windows pour TOUS les scénarios problématiques.
   où # 6783 est l'un d'entre eux

2. Je peux considérer ce problème comme: problème de vitesse pour la plaisanterie [Mac vs Windows] pour TOUS les scénarios problématiques.

J'ai essayé avec les deux versions à ce moment de la publication.

Je viens de créer un nouveau projet avec un test avec de simples tests push de tableau et cela a pris plus de 10 secondes du début à la fin. Le projet utilise react / typescript mais le fichier de test n'est pas un fichier de composant react mais un fichier normal comme un .js. Gif ci-dessous pour référence visuelle s'il est préférable de visualiser quel pourrait être le problème:

J'ai remarqué que la première fois que j'exécute le test, cela montre que le test est estimé à 9 secondes. Une fois terminé, il relance les tests au hasard une deuxième fois jusqu'à la fin.

Lorsque j'ai pris cette photo gif ci-dessus (ce qui était la deuxième fois cette fois), le temps estimé a diminué un peu et il n'a pas effectué une deuxième tentative. Je ne sais pas si c'est le comportement de plaisanterie attendu.

Voici un gif de moi exécutant micromatch 4 avec du fil dans un projet séparé:

L'utilisation de Windows 10 et les spécifications de mon ordinateur sont:
Processeur AMD FX (tm) -8320 à huit cœurs 3,50 GHz
16 Go de RAM
x64
SSD

Permettez-moi de partager mon profil ici.
Spécifications:

• Windows 10 Professionnel
• Nœud 10.15.3
• Intel Core i7-4702MQ 2,2 GHz
• 8 Go de RAM
• x64
• SSD

Pas:

1. npx create-react-app my-app --typescript
2. changer App.test.tsx
3. exécuter npm test

Profil du processeur:

CPU-20190801T141211.zip

Est-il prévu que 15 secondes soient passées uniquement avec des modules requis pour un seul composant et test trivial de React?

Quelqu'un avec plus d'expérience sur le profilage du processeur peut-il jeter un coup d'œil?

112 tests
fenêtres 10
première exécution 507 secondes
deuxième manche 23 secondes
sous-système Linux
première course 54 secondes
deuxième manche 29 secondes

85 tests
fenêtres 10
première exécution 44 secondes
deuxième manche 15 secondes
sous-système Linux
première exécution 26 secondes
deuxième manche 15 secondes

Kepro ces résultats sont avec micromatch 4?

Je préfère le chat direct que d'avoir 1 million de messages ici, ça devient vraiment un enfer de suivre toutes les questions liées au même sujet.
Vous pouvez rejoindre ici. https://gitter.im/wearefrontend/jest-slow-windows
Je suis dessus maintenant ...

Gitter est bloqué sur le VPN de mon entreprise - si vous, des gens charmants, pouviez publier des mises à jour significatives ici, ce serait incroyable <3

vous pouvez toujours vous connecter à la maison pour faire de l'open source: P et le vérifier
ps un jeu dota prend plus de temps à faire la queue maintenant vous pouvez vérifier gitter à ce moment;)
c'est ici que c'est maintenant: nodejs / node # 28946

@nasreddineskandrani Vous m'avez eu. J'ai commandé un nouveau macbook et je serai donc hors de l'action open source jusqu'à ce qu'il arrive. Je refuse de travailler sur ma machine Windows merdique pendant mon temps libre: D

Il semble que le problème se soit déplacé vers le domaine node / C ++, qui est un peu (extrêmement) en dehors de ma zone de confort - mais je vais creuser!

Salut des nouvelles à ce sujet?

Pour contourner ce problème, vous pouvez utiliser --runInBand si vous démarrez plusieurs tests. Il faudra encore longtemps pour démarrer le premier test mais les prochains tests seront rapides.

Mon projet a nécessité 21 803 secondes pour exécuter tous les tests.
Maintenant, avec --runInBand, cela ne prend que 7,412 secondes

--runInBand pour moi, faites-le encore plus lentement. 1200 tests. Sans runinBand 70/50 secondes. Avec --runInBand ses 90 secondes sur la deuxième manche au mieux
Sur Linux, c'est 5-8x plus rapide

Essayez --maxWorkers = 4 alors.

@ cino893 , pas une solution :) essayez de trouver un correctif pas une solution de contournement

Des nouvelles à ce sujet? J'ai empilé sur la version 21 à cause de ce bogue. La v22 est lente et la v23 est encore plus lente.
Vous ne pensez pas que c'est un bug hautement prioritaire?

Là où je travaille, nous n'avons pas la liberté de choisir le système d'exploitation ni d'installer Ubuntu sur Windows ou quelque chose de similaire.

@gombek avez-vous essayé la v25? L'équipe Jest a apporté de nombreuses améliorations de performances à tous les niveaux.

Salut, je pensais juste ajouter des informations supplémentaires à cette discussion. Jest est très lent également lorsqu'il est exécuté dans un conteneur Docker dont le code source et les tests sont partagés via le volume du système hôte (Windows).

Je suis à peu près certain que ce ralentissement est dû aux différences dans la façon dont Windows gère les descripteurs de fichiers par rapport aux systèmes Unix. Sous Unix, si un processus a un descripteur de fichier ouvert qui n'empêche pas les autres processus de lire ce fichier. Sous Windows, un processus contenant un descripteur de fichier possède ce fichier tant qu'il libère le descripteur. Je regarderais dans le code Jest pour la logique de lecture de fichiers et en particulier quand et comment les descripteurs de fichiers sont libérés. Un programme qui se comporte bien devrait de toute façon libérer les descripteurs de fichiers immédiatement après avoir fait son travail. De toute façon, un testeur comme Jest ne devrait avoir aucune raison de tenir le descripteur de fichier pendant longtemps.

@gombek avez-vous essayé la v25? L'équipe Jest a apporté de nombreuses améliorations de performances à tous les niveaux.

J'utilise Jest v25 sur Windows et c'est encore lent

@pfftdammitchris J'ai comparé des suites de tests assez complexes sur Mac + Windows et je vois quelques différences, principalement à partir d'un cache froid Windows est notablement plus lent, mais une fois qu'il fait chaud, j'obtiens des performances similaires entre les deux.

TOUTEFOIS...

Une chose à laquelle il faut être extrêmement prudent sur Windows en particulier sont les programmes intrusifs au niveau du noyau comme les antivirus / les observateurs de fichiers comme Carbon Black (ou d'autres logiciels de surveillance de fichiers en temps réel). Si vous avez quelque chose comme cette course, vous pouvez voir d' énormes succès de performances lors de l' exécution Jest. Je parle qu'il faut des dizaines de minutes pour exécuter des tests.

J'ai travaillé pour une entreprise l'année dernière où la même suite de tests prenait environ 30 secondes sur un Macbook Pro et 20 minutes sur un ordinateur portable Windows avec ces programmes de surveillance de fichiers en cours d'exécution.

Je ne sais pas pourquoi, mais je devinerais que c'est quelque chose à voir avec les descripteurs de fichiers et comment Jest utilise certaines des API du système de fichiers node.js.

Je n'ai qu'environ 20 tests et je viens de prendre quelques timings avec jest --watch, à la fois lors de la première exécution et en appuyant sur Entrée pour les réexécuter.

Sous Windows, cela a pris environ 15 secondes les deux fois, tandis que pour Linux, il était d'environ 5,3 secondes pour la première exécution et 2,3 pour les exécutions suivantes.

J'ai essayé d'utiliser -t = "GARBAGE" pour faire sauter tous les tests. celui de linux a pris 1,5 seconde mais Windows en a quand même pris 13, donc il me semble que ce n'est pas l'exécution réelle des tests qui prend le temps!

Les deux machines utilisent la dernière version de node and jest, et le Linux est en fait une machine virtuelle fonctionnant à l'intérieur de Windows utilisant hyper-v, donc toutes choses étant égales par ailleurs, je m'attendrais à ce que Windows soit plus rapide.

Je n'ai qu'environ 20 tests et je viens de prendre quelques timings avec jest --watch, à la fois lors de la première exécution et en appuyant sur Entrée pour les réexécuter.

Sous Windows, cela a pris environ 15 secondes les deux fois, tandis que pour Linux, il était d'environ 5,3 secondes pour la première exécution et 2,3 pour les exécutions suivantes.

J'ai essayé d'utiliser -t = "GARBAGE" pour faire sauter tous les tests. celui de linux a pris 1,5 seconde mais Windows en a quand même pris 13, donc il me semble que ce n'est pas l'exécution réelle des tests qui prend le temps!

Les deux machines utilisent la dernière version de node and jest, et le Linux est en fait une machine virtuelle fonctionnant à l'intérieur de Windows utilisant hyper-v, donc toutes choses étant égales par ailleurs, je m'attendrais à ce que Windows soit plus rapide.

Oui. Et si vous montez les codes sources sur la machine virtuelle Linux à partir de Windows et exécutez les tests, ils deviennent aussi lents que sous Windows. Cela implique fortement que le problème est dans la logique de gestion des fichiers de Jest comme je l'ai mentionné plus tôt.

Oui. Et si vous montez les codes sources sur la machine virtuelle Linux à partir de Windows et exécutez les tests, ils deviennent aussi lents que sous Windows. Cela implique fortement que le problème est dans la logique de gestion des fichiers de Jest comme je l'ai mentionné plus tôt.

J'ai remarqué que lorsque les tests sont en cours d'exécution, le processeur est élevé, mais l'utilisation du disque ne l'est pas. C'était à voir avec le blocage des descripteurs de fichiers, je m'attendrais à ce que le processeur soit faible (à moins que la plaisanterie ne soit en quelque sorte dans une boucle serrée en attendant que les poignées soient libérées)

J'ai vu les commentaires de hevans90 sur les observateurs de fichiers. Je n'ai aucun antivirus tiers installé ou similaire, mais la désactivation de la protection en temps réel intégrée de Windows n'a fait aucune différence notable.

espérons que cela pourrait aider quiconque a le temps d'essayer de le déboguer.

J'ai donc confirmé aujourd'hui que Windows Defender fait une énorme différence.
J'avais l'habitude d'avoir un tas d'exclusions, mais quand j'ai reçu mon nouvel ordinateur portable plus rapide, je n'ai pas pu comprendre pour la vie de moi pourquoi la plaisanterie a pris> 10 minutes pour exécuter un seul fichier.

Puis je me suis souvenu des exclusions.
Je ne peux pas dire exactement quelles exclusions font la différence, mais j'ai demandé au coureur de descendre à <15sec au lieu de> 10 minutes

J'ai trouvé l'essentiel avec des exclusions pertinentes (quoique énergiques)
https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196
J'ai également ajouté des extensions de fichier .ts .js .spec.ts .spec.js .tsx

Je ne peux pas dire exactement quelles exclusions font la différence, mais j'ai demandé au coureur de descendre à <15sec au lieu de> 10 minutes

hmm, je viens d'essayer et cela ne semble pas faire de différence par rapport au mien

De toute façon, j'ai toujours des exclusions en place. Et en fait, IntelliJ Idea suggère automatiquement de placer le répertoire de l'espace de travail dans des exclusions et le fait pour vous si vous le laissez (vous devriez). Donc, dans mon cas, la lenteur n'est pas due à Windows Defender ou à tout autre antivirus.

La différence de performances est de 5 à 10 fois par rapport à un Mac. Le PC est une machine de bureau puissante (lire: beaucoup plus rapide que le macbook). Tout le reste est rapide comme l'éclair, juste Jest souffre de ce problème.

des mises à jour à ce sujet? ... je vis la même chose, chaque test prend beaucoup de temps à installer et à charger, mais une fois le premier chargé, il fonctionne à une vitesse normale .....

Avoir également ce problème. Un seul fichier de test avec un seul test Hello world et il faut environ 15 secondes pour démarrer, plus 12 secondes supplémentaires pour exécuter le test.

👋 Je vois quelques réponses suggérant qu'ils utilisent du dactylographie avec jest - cela pourrait valoir la peine d'être examiné (si vous utilisez également ts-jest): https://github.com/kulshekhar/ts-jest/issues/ 908 # issueecomment -484043250

Le changement pour moi allait d'attendre 30 minutes pour plaisanter (sans cache) pour commencer à quelques secondes.

Gardez à l'esprit que la définition de l'indicateur isolatedModules n'entraînera aucune vérification de type pour vos fichiers de spécifications (et la perte de certaines fonctionnalités): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

Je ne poste que ceci ici car il pourrait être utile de déterminer si votre problème est avec jest.

👋 Je vois quelques réponses suggérant qu'ils utilisent du dactylographie avec jest - cela pourrait valoir la peine de regarder (si vous utilisez également ts-jest): kulshekhar / ts-jest # 908 (commentaire)

Le changement pour moi allait d'attendre 30 minutes pour plaisanter (sans cache) pour commencer à quelques secondes.

Gardez à l'esprit que la définition de l'indicateur isolatedModules n'entraînera aucune vérification de type pour vos fichiers de spécifications (et la perte de certaines fonctionnalités): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/ config / isolatedModules.md

Je ne poste que ceci ici car il pourrait être utile de déterminer si votre problème est avec jest.

JavaScript pur ici. J'ai ce problème donc pas lié à TypeScript.

FYI: https://github.com/kulshekhar/ts-jest/pull/1549 sera en version alpha de ts-jest (peut-être aujourd'hui). Quiconque utilise ts-jest, aidez-nous à tester la version alpha et donnez-nous quelques commentaires pour https://github.com/kulshekhar/ts-jest/issues/1115

Avoir également ce problème. Un seul fichier de test avec un seul test Hello world et il faut environ 15 secondes pour démarrer, plus 12 secondes supplémentaires pour exécuter le test.

J'ai juste exécuté le même test sur un Mac. Il faut environ 1,5 seconde pour démarrer, <1 seconde pour exécuter le test.

Utilisant également JS, pas TS ici.

JavaScript pur avec Jest également ici. J'ai un puissant ordinateur portable quadricœur avec les processeurs 10gen d'Intel et tout le reste est ultra-rapide, mais [email protected] prend 2-3 fois plus sous Windows que Linux pour exécuter des tests de base.

Même problème, environ 60 secondes pour que mes tests s'exécutent sur Windows, et aucune interface utilisateur ne s'affiche pendant les 45 premières secondes environ. J'ai exécuté exactement la même suite de tests sur ma machine Linux et cela a pris 8 secondes pour se terminer.

Le commentaire de @Cellule ci-dessus a accéléré considérablement les choses à environ 15 secondes.

@ryanrapini a suivi les conseils de @Cellule (mais est passé par le Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions ) et a vu que certains tests sont passés de 13 secondes à 6, donc essentiellement la moitié. Merci!

Quelqu'un veut-il contribuer à une section mentionnant Windows Defender (ou AV en général?) Sur la page FAQ du site Web? https://jestjs.io/docs/en/troubleshooting

Je peux confirmer que l'utilisation de isolatedModules: true avec ts-jest a fait une énorme différence au démarrage à froid (~ 10mins => 15sec)
Je n'ai pas testé leur amélioration dans l'alpha car j'attends que le # 9457 soit adressé avant de passer à jest 25

Salut à tous,

Même problème ici et aucune solution ne fonctionne pour moi ...

Je lance un code très simple sur lequel j'ai actuellement quelques tests.
C'est du "Advanced React Course" de Wes Bo.
Il l'exécute sur Mac et obtient une réponse immédiate de son ordinateur.

Et pour moi:

Suites de tests: 2 sautées, 15 réussies, 15 sur 17 au total
Tests: 6 sautés, 37 réussis, 43 au total
Instantanés: 18 réussis, 18 au total
Temps: 5.869s
Ran toutes les suites de tests.

isolatedModules: true ne change rien dans mon cas, je suis encore environ 5-6 secondes.
Et quand je commence à tester avec n'importe quelle option, cela prend 9 ~ 10 secondes.

L'ajout de mon dossier de développement sur les exceptions Defender n'a rien fait non plus:

Suites de tests: 2 sautées, 15 réussies, 15 sur 17 au total
Tests: 6 sautés, 37 réussis, 43 au total
Instantanés: 18 réussis, 18 au total
Temps: 5.563s
Ran toutes les suites de tests.

Existe-t-il une bonne option sous Windows?
Dois-je opter pour WSL2?

Salut à tous,

Même problème ici et aucune solution ne fonctionne pour moi ...

Je lance un code très simple sur lequel j'ai actuellement quelques tests.
C'est du "Advanced React Course" de Wes Bo.
Il l'exécute sur Mac et obtient une réponse immédiate de son ordinateur.

Et pour moi:

Suites de tests: 2 sautées, 15 réussies, 15 sur 17 au total
Tests: 6 sautés, 37 réussis, 43 au total
Instantanés: 18 réussis, 18 au total
Temps: 5.869s
Ran toutes les suites de tests.

isolatedModules: true ne change rien dans mon cas, je suis encore environ 5-6 secondes.
Et quand je commence à tester avec n'importe quelle option, cela prend 9 ~ 10 secondes.

L'ajout de mon dossier de développement sur les exceptions Defender n'a rien fait non plus:

Suites de tests: 2 sautées, 15 réussies, 15 sur 17 au total
Tests: 6 sautés, 37 réussis, 43 au total
Instantanés: 18 réussis, 18 au total
Temps: 5.563s
Ran toutes les suites de tests.

Existe-t-il une bonne option sous Windows?
Dois-je opter pour WSL2?

Pouvez-vous essayer d'appliquer ma solution et me dire si elle fait quelque chose? (en fait la solution de Cellule, mais je l'ai fait via le menu au lieu d'exécuter un script)

Pouvez-vous essayer d'appliquer ma solution et me dire si elle fait quelque chose? (en fait la solution de Cellule, mais je l'ai fait via le menu au lieu d'exécuter un script)

Comme je l'ai dit dans mon message, je l'ai déjà fait :)

Je veux dire, j'ai suivi ce que vous avez fait, via le menu et tout.

J'ai également ce problème sous Windows. Le test lui-même s'exécute en <1 seconde mais la configuration globale prend ~ 15 secondes pour s'exécuter. Je l'ai essayé avec v24 et v26, c'est en fait un peu plus lent sur v26

Je n'ai eu de chance avec aucun des éléments suivants (cela n'a pas amélioré le temps d'exécution):

• ajout de --runInBand
• réglage maxWorkers
• ajouter .ts .js .spec.ts .spec.js .tsx exclusions à Virus and Threat Protection , comme suggéré par @Cellule et @alessioalex

Même problème sous Windows ici avec du javascript vanille ainsi qu'un nouveau projet typographique. 2 secondes pour exécuter 9 tests unitaires qui s'exécutent en <10 ms en utilisant mocha.

C'est fou!

Simplement installé jest globalement et maintenant exactement le même projet s'exécute en 0.9s au lieu de 52 (!!!) secondes!
npm remove jest dans le projet, puis
npm install -g jest

Bien sûr, j'aimerais à nouveau intégrer jest en tant que dépendance de développement dans le projet. Une idée de pourquoi cela se produit?

C'est fou!

Simplement installé jest globalement et maintenant exactement le même projet s'exécute en 0.9s au lieu de 52 (!!!) secondes!
npm remove jest dans le projet, puis
npm install -g jest

Bien sûr, j'aimerais à nouveau intégrer jest en tant que dépendance de développement dans le projet. Une idée de pourquoi cela se produit?

Cela me semble très certainement être un problème de scanner de virus. Cela signifie que le répertoire de votre projet est dans le cadre de l'analyse antivirus, ce qui ralentit la plaisanterie en une analyse, mais votre répertoire global npm ne l'est pas. Ce n'est qu'une idée cependant.

J'ai juste essayé la même chose que @JPustkuchen et les performances vont de ~ 10s à <1 seconde.

J'ai exclu mon dossier de projet de Windows Defender mais Jest est toujours lent.

Je ne sais pas si cela est toujours en cours de travail, mais je remarque que lorsque je fais une faute de frappe dans le code, les tests en mode montre échouent instantanément. Ce qui m'amène à penser qu'il ne s'agit pas de forcer une nouvelle exploration de répertoire avant de compiler le test. Des tests très simples me prennent également 10 secondes.

Je souhaiterais tellement que quelqu'un reconnaisse au moins que c'est un problème. Dans l'état actuel des choses, ma machine de bureau Windows qui a beaucoup de puissance (lire: bien plus que le macbook de mes collègues) est environ 69 fois plus lente que le macbook lors de l'exécution des tests! Cela m'oblige pratiquement à ne pas toucher au code du frontend car il est tellement inefficace pour moi de travailler sur ceux-ci à cause des tests Jest qui fonctionnent si lentement. Nous devrons peut-être nous éloigner de Jest si cela ne se résout pas. Tout le reste est ultra-rapide, mais les tests Jest sont extrêmement lents. Le temps est consacré à autre chose que l'exécution réelle des tests, lorsque la logique de test réelle est exécutée, ceux-ci vont très vite.

Sur une note plus positive, je voudrais juste dire que je dois à ce bug une grande dette de gratitude. C'est la goutte d'eau qui m'a poussé à passer à Linux pour mon flux de travail de développement principal et je n'ai jamais été aussi heureux. Je ne peux pas dire que je n'y retournerai jamais parce que parfois je dois travailler sur des projets hérités, mais avec ASP.NET core étant multiplateforme, les raisons de redémarrer sous Windows sont de moins en moins nombreuses.

S'il vous plaît @ timrobinson33 restons sur le sujet. Il n'y a aucune raison jest laquelle

J'ai testé avec v26.4.2 dans mon repo jest github de référence.
https://github.com/nasreddineskandrani/benchmark_jest
version du nœud sur mon ordinateur: v12.13.0

assez bien quand je mets à jour le test simple (voir capture d'écran)! Pour moi, la plaisanterie est maintenant correcte pour un simple test.
Si vous avez un problème au travail. Vous devez essayer d'isoler le problème car par défaut, tout va bien.

@empperi pouvez-vous essayer mon repo de référence. exemple avec le dossier v26 et dites-moi combien de temps il faut pour exécuter ce test sur votre machine? si ce n'est pas 0,166 ms ou autour, vous avez un problème de votre côté.

J'ai testé avec v26.4.2 dans mon repo jest github de référence.
https://github.com/nasreddineskandrani/benchmark_jest
version du nœud sur mon ordinateur: v12.13.0

assez bien quand je mets à jour le test simple (voir capture d'écran)! Pour moi, la plaisanterie est maintenant correcte pour un simple test.
Si vous avez un problème au travail. Vous devez essayer d'isoler le problème car par défaut, tout va bien.

@empperi pouvez-vous essayer mon repo de référence. exemple avec le dossier v26 et dites-moi combien de temps il faut pour exécuter ce test sur votre machine? si ce n'est pas 0,166 ms ou autour, vous avez un problème de votre côté.

Comme prévu, aucune différence dans les performances de votre configuration de test. Fonctionne en fait un peu plus vite que sur votre ordinateur. Modification de votre configuration de test pour contenir 100 fichiers de test de moins de __tests__ et ceux-ci fonctionnent correctement. Étant donné que notre application utilise react-scripts j'ai également ajouté cela à votre exemple pour vérifier si cela pourrait causer le problème réel, mais aucune différence de performances.

CEPENDANT, j'ai essayé d'exécuter ces tests dans WSL2 bash (contre le système de fichiers NTFS) et boom, temps d'exécution près de 10x au PowerShell brut. Une vitesse d'E / S plus lente est à prévoir sur WSL2 par rapport à NTFS, mais compte tenu de la simplicité de cette configuration (seulement 100 fichiers de test avec un seul test sur chacun), cela ne devrait vraiment pas affecter autant. Pour référence, j'ai exécuté ceci sur WSL2 bash:

time find . -name "*.js" -print | xargs cat
...(file content prints omitted)...
real    0m0.138s
user    0m0.030s
sys     0m0.000s

Ce qui montre que la lecture du système de fichiers à partir de WSL2 ne prend pratiquement pas de temps. Pour référence une commande similaire dans Powershell:

> Measure-Command { ls *.js | % { cat $_ } }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 49
Ticks             : 499000
TotalDays         : 5,77546296296296E-07
TotalHours        : 1,38611111111111E-05
TotalMinutes      : 0,000831666666666667
TotalSeconds      : 0,0499
TotalMilliseconds : 49,9

Ce qui montre que la performance est sur le même terrain.

Donc, sur cette base, je dirais que le problème pourrait être causé par la façon dont Jest utilise les E / S et que cela affecte considérablement les performances sur WSL2. En ce qui concerne le projet qui me cause des problèmes, ce n'est pas une tâche simple de ne pas avoir besoin de bash en raison de problèmes de code et de tests (pas fait par moi!). Compte tenu du fait que WSL2 gagne en popularité, je dirais que c'est un vrai problème qui devrait être examiné.

J'espère que cela t'aides.

:Éditer:

Juste par curiosité, j'ai exécuté notre suite de tests avec --no-watch pour voir si l'observation du système de fichiers sur WSL2 affecte d'une manière ou d'une autre les choses. La réponse est non, cela n'affecte vraiment pas grand-chose.

L'exécution du benchmark sur ma machine Windows prend environ 1,6 seconde. Je n'utilise pas WSL.
J'utilise l'antivirus AVG, mais j'ai ajouté des exceptions pour le référentiel et l'exécutable du nœud.
Mon disque dur est un SSD.

La version du nœud est v12.16.1

La mise à jour du test déclenche instantanément l'observateur de fichiers, mais le temps réel nécessaire pour exécuter cette mise à jour est d'environ 1 s à 2,4 s.

Je voulais tester si c'est l'environnement qui pose problème.

Je plaisantais avec ce dépôt: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• Je pars pour npm test et tous les tests commencent à s'exécuter en mode montre.
• J'appuie sur 'p' pour entrer un modèle pour un fichier et je tape "tdd-02". J'obtiens plus de 3 secondes de temps d'exécution.
  

Je serais surpris si Kent C. Dodds a un environnement foiré dans son cours payant, mais s'il le fait, vous pouvez probablement le déboguer là-bas:? Dans ses vidéos, ça marche très bien, je pense qu'il utilise un Mac.

Je dois noter quelque chose de très étrange que je ne peux pas reproduire à nouveau - j'ai eu quelques réexécutions de test consécutives pour l'un des fichiers (tdd-02 ... js) exécutés pendant environ 0,1 s, et pour le fichier à côté ( tdd-01 ... js) - environ 3 s. Le code est presque le même et utilise les mêmes dépendances. J'ai donc copié le code du fichier à exécution rapide et l'ai collé dans celui à exécution lente et vice versa. Les résultats étaient les mêmes: le fichier à exécution lente restait lent et le fichier à exécution rapide restait rapide, les codes réels étant échangés. Cela devient fou. Maintenant, les deux fichiers fonctionnent à nouveau lentement (3-6s).

@Glinkis pouvez-vous essayer d'

@SimeonRolev je vais jeter un œil à l'exemple que vous avez posté et voir quel type de numéro je reçois avec les mêmes étapes (modèle ...)
mettre à jour:
try1: je l'ai essayé comme u et j'ai obtenu 6sec quand j'ai essayé vos étapes -> passez à 3sec en réexécutant le même test (appuyez sur Entrée)
try2: jest amélioré à 26.4 dans le repo Kent -> 3 sec première exécution presque identique pour la réexécution
try3: J'ai pris le fichier index.spec.js de mon dépôt de test de référence. et je l'ai déposé dans le repo Kent. (suppression de tous les autres fichiers de test) -> surprise 2.8sec (MÊME JEST 26.4.2, MÊME ORDINATEUR, POWERSHELL, NODE_VERSION etc ... comme mon test posté hier ici)

Je ne comprends toujours pas ce try3 => ~ 3sec lors de la réexécution dans le repo Kent pour mon fichier mais dans mon repo, il tombe à 0.300s lors de la réexécution (besoin de quelqu'un pour déboguer cela)
edit: Kent devrait être celui qui vérifie ceci: P

En appuyant sur Entrée, le test dure environ 200 ms.

@nasreddineskandrani Avez-vous essayé l'inverse? Je veux dire, copier les tests du repo lent vers le vôtre? Mais je ne pense pas que le problème soit lié au repo que j'ai publié. Comme nous pouvons le voir clairement, beaucoup de gens ont le même problème, je viens de publier un exemple reproductible.

@kentcdodds Serez-vous notre héros une fois de plus?

@SimeonRolev Dans mon benchmark, je ne vois pas le même problème que dans le repo Kent. Vous avez quelque chose dans Kent Repo. qui causent ce lent => en dehors de la plaisanterie est plus rapide.

Ce problème de github est lié aux fenêtres de performance Jest par rapport à macOS / Linux car elles n'ont pas atteint les mêmes performances. ils ne l'ont pas stipulé, je suppose. (c'est bien mieux maintenant qu'il y a 2 ans avec jest v23)

Bonjour, je rencontre le même problème ici. J'ai une machine Windows et WSL. J'ai copié mes fichiers de projet sur WSL pour tester ce comportement. Voici les exécutions des deux mêmes tests de base:
Windows 10 (version 2004):

WSL 2 (Ubuntu 20.04):

Les tests sont très simples:

Le projet est créé avec CRA, donc il n'y a pas de configuration pour bâcler les paramètres, je n'ai rien ajouté en termes de Jest.
Les mêmes tests se déroulent à une vitesse fulgurante sur le moka, presque instantanément. J'essaie de mettre en place un environnement de test pour notre projet, et j'aimerais vraiment utiliser Jest, mais il semble qu'au fur et à mesure que j'ajoute de plus en plus de tests, la suite de tests sera de plus en plus lente. Chaque test semble ajouter 0,8 seconde, ce qui est ridicule, car ils ne font rien. Il y a un problème avec l'exécution des tests sous Windows, et je ne sais pas quoi.
Le problème était pire, un seul test prendrait environ 15 secondes, mais quand j'ai ajouté --runInBand et, la situation semblait s'améliorer un peu, mais je pense que ce n'est toujours pas suffisant, étant donné que le mode montre moka est instantané.

Yarn est la version 1.22.5, toutes les autres dépendances npm (comme react et react-scripts) sont les plus récentes.

J'ai désactivé l'antivirus et Windows Defender pour voir si cela avait un effet, mais ce n'est pas le cas. En outre, j'ai désactivé l'indexation pour mon dossier de projet, en vain non plus.

Edit: J'ai essayé d'appuyer sur Entrée, et les tests étaient aussi rapides que sur WSL:

Maintenant je suis vraiment confus :)

Mais cela semble encore très lent, car il semble que chaque test dure 0,3 seconde, ce qui est beaucoup, étant donné qu'ils ne font rien. Je m'attends à ce que cette suite soit terminée en moins de 0,1 seconde.

Edit 2: Lorsque j'ai ajouté 100 tests à ma suite de tests, il a fallu environ 44 secondes pour les exécuter, même si j'appuie sur Entrée pour les exécuter:

Les mêmes suites de tests prennent environ 9 à 10 secondes sur WSL: