Yarn: Besoin d'une grande optimisation pour Windows

+1

Salut @OshotOkill! Merci d'avoir essayé Yarn. Utilisez-vous Cygwin ou WSL («Bash sur Ubuntu sous Windows»)? Les deux sont connus pour avoir de très mauvaises performances d'E / S de disque.

De plus, React Native a un grand nombre de fichiers, donc les copier dans node_modules est assez lent, et les E / S disque pour beaucoup de petits fichiers sous Windows sont généralement plus lentes que Mac OS (qui lui-même est plus lent que Linux ext4). Nous avons pour tâche d'expérimenter les liens physiques (# 499) qui devraient améliorer les performances dans ce scénario.

Pas de cache et même environnement réseau

La principale amélioration avec Yarn est lorsque vous avez un cache chaud (c'est-à-dire après avoir installé un paquet au moins une fois), mais avec React Native, le grand nombre de fichiers sera également une cause de la lenteur.

@ Daniel15 Non, je n'utilise pas Cygwin / MinGW / MSYS2 ou WSL (ce dernier échoue en raison d'un bug épineux).

Selon votre description, je peux supposer que le problème est causé par le système de fichiers (NTFS), n'est-ce pas? Même s'il existe un cache chaud, le processus de copie est toujours beaucoup plus lent que MacOS.

J'espère que les équipes de développement pourront trouver une solution dès que possible. Merci.

Je vois la même chose.

Faites installer, effacez node_modules, installez

MacBookPro prend 17 secondes, ma machine Windows prend 122 secondes.

Quelqu'un a fait remarquer que cela pourrait être lié à un logiciel antivirus qui analyse les node_modules et le cache global de fils en continu. Pouvez-vous essayer de le désactiver pour ces dossiers?

@cpojer Je suppose qu'ils ont raison. Je n'ai pas de logiciel antivirus sur ma machine à l'exception de Windows Defender préinstallé, j'ai donc interdit l'analyse du dossier de cache global et de mon dossier de projet et j'ai fait quelques tests:

Par défaut: 128,08 s

Pas d'analyse du dossier cache: 104,43 s

Pas de numérisation du dossier du projet: 78,28 s

Pas d'analyse du dossier cache et du dossier projet: 53,48 s

Bien qu'il soit plus lent que Mac pendant 10 + s, il a un coup de pouce significatif.

Cela devrait être informé des documents officiels, je pense.

Quelqu'un a fait remarquer que cela pourrait être lié à un logiciel antivirus qui analyse les node_modules et le cache global de fils en continu.

Bonne prise! J'ai totalement oublié cela car j'ai déjà c:\src liste blanche sur mes ordinateurs.

@OshotOkill - Souhaitez-vous soumettre une demande d'extraction en ajoutant une note sur les applications antivirus sur le site Web, dans les instructions d'installation de Windows? Voici le fichier que vous devez modifier: https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md (vous pouvez le modifier directement sur Github). Ce serait apprécié 😄

Je n'étais pas aussi méticuleux que @OshotOkill , mais j'ai ajouté des exceptions pour ma source et mon dossier d'installation de nœud, puis j'ai spécifiquement exempté les binaires yarn, npm et node et maintenant ma nouvelle durée d'installation sur Windows est réduite à 50 secondes contre 122 secondes .

@ Daniel15 PR est prêt. Excusez-moi pour mon mauvais anglais.

PR a été fusionné. Fermez ce problème.

Ceci est encore douloureusement lent sur Windows, même en désactivant l'antivirus et Windows Defender. Je ne pense pas que ce soit juste un problème d'environnement (comme cette solution antivirus), mais il semble que yarn essaie de copier tous les fichiers, 1 par 1, même si vous installez des dépendances sans rapport.

Pourquoi ne pas simplement supprimer / copier les fichiers qui doivent changer? Si webpack installé et n'est pas modifié lorsque j'ai installé rimraf , il ne devrait pas avoir à être copié à nouveau du cache vers le dossier node_modules local.

J'ai également créé un article StackOverflow à ce sujet: http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

Au fait, dans mes benchmarks Ubuntu (à double démarrage), j'utilisais le même lecteur NTFS que celui sur lequel Windows fonctionne normalement; et c'est toujours rapide là-bas.

L'ajout de node.exe aux exclusions de Windows Defender m'a donné une énorme amélioration des performances http://126kr.com/article/1884rsed7l

Je vais certainement essayer ça!

Cela a semblé améliorer un peu la vitesse 212 -> 170 secondes
Cela semble donc aider, mais cela pourrait encore être amélioré, car il est toujours plus de 3 fois plus lent que sous Linux

Un autre problème que j'ai remarqué - Le service d'indexation sur Windows essaie d'indexer chaque fichier dans node_modules.
Je n'en ai pas vraiment besoin du tout, alors je l'ai désactivé http://www.softwareok.com/?seite=faq-Windows-10&faq=53 et j'ai obtenu un autre gain de performances.

Mes fenêtres ne sont pas configurées pour indexer le chemin en question, donc cela ne résout toujours pas le problème.

Donc, pour résumer, il existe 4 façons d'améliorer les performances:

• Dossier de projet de la liste blanche de AV
• White While the Yarn cache directory ((% LocalAppData% Yarn)) from AV
• Ajout de node.exe aux exclusions de Windows Defender
• Désactivation du service d'indexation sous Windows sur le dossier node_modules

@Altiano oui, mais ce n'est toujours pas suffisant pour obtenir des performances même proches de Mac / Linux

Semble assez sommaire que vous deviez désactiver AV ou l'indexation sur les répertoires pour faire du fil aussi rapide ou plus rapide que npm. Après tout, vous n'êtes pas obligé de faire cela pour npm. J'ai décidé d'essayer le fil parce qu'il déclarait que c'était rapide et que les installations hors ligne rendaient le codage sans connexion réseau plausible. N'existe-t-il aucun moyen d'optimiser la liaison?

Selon certains problèmes qui se rapportent ici et les commentaires ci-dessus, je voudrais rouvrir ce numéro afin de rassembler d'autres solutions.

Personnellement, je suggère de lister les configurations matérielles de votre machine de test et de télécharger quelques photos associées. Il pourrait y avoir de nombreux autres éléments non pertinents qui font une grande différence entre les plates-formes plutôt que Yarn lui-même, c'est-à-dire que les performances de référence du SSD sur un MacBook sont généralement bien meilleures qu'une machine Windows.

@OshotOkill comme je l'ai dit plus tôt, j'ai eu des performances 3,5 fois plus lentes sur Windows vs Linux avec des index et Windows Defender désactivés pour les répertoires concernés, sur le même PC normal sur le même lecteur _ntfs_. Que même sur ntfs, c'est beaucoup plus rapide sous Linux en dit long, je pense.

Voyons la raison de cela.
Est-ce que NTFS fonctionnait plus lentement sur un grand nombre de fichiers déplacés pendant l'installation?

Quelqu'un peut-il partager un moyen de reproduire cela sur une seule machine?
Par exemple, un package.json particulier installé sur un ordinateur portable Windows prend X secondes mais s'exécute dans VirtualBox Ubuntu X-20% secondes.

@amcsi @bestander Comme c'est souvent le cas, EXT4 / XFS sont plus rapides lors de la copie de grandes quantités de petits fichiers. Cependant, NTFS n'est pas beaucoup plus lent. Je viens de nettoyer le cache et de tester à nouveau en utilisant la dernière version de Yarn and Node (0.19.1 & 7.5.0):

Le résultat est vraiment proche d'un MacBook lors de l'installation de react-native . Tout ce que j'ai fait, c'est simplement mettre sur liste blanche les dossiers associés et le processus Node.exe.

J'avais moi-même ce problème jusqu'à ce que j'aie mis sur liste blanche les processus node.exe et yarn.exe dans Windows Defender, ainsi que mon répertoire de projet. Je n'ai pas du tout désactivé l'indexation de la recherche et je n'ai pas ajouté le répertoire de cache Yarn. Les temps d'installation sont passés de plus de 190 secondes sur un projet de taille moyenne à environ 25 secondes à partir d'un cache propre. Ma machine Ubuntu est juste un peu plus rapide que cela, mais seulement de 5 à 10 secondes.

Configuration matérielle:
SSD de 512 Go
12 Go de RAM
Processeur AMD FX-8350 à 8 cœurs à 4,01 GHz
Windows 10 64 bits, build 14986.

J'ai juste fait quelques tests rapides sur mon propre système. J'ai Linux Mint et Windows 10 à double démarrage sur le même SSD. J'ai nettoyé mon cache de fils, supprimé node_modules et exécuté yarn sur ce projet vue .

Linux Mint: _12.22s_

Windows 10 (pas de liste blanche): _64.32s_

Windows 10 (avec liste blanche): _42.58s_

Voici les exclusions de Windows Defender que j'avais actives:

Bien que la liste blanche semble avoir un effet significatif, elle n'est toujours pas proche de la vitesse sur Linux.

EDIT: Pour @bestander , voici mes données normalisées:

| OS | Calcul | Données normalisées |
| --- | --- | --- |
| Linux Mint | 12,22 / 12,22 | 1 |
| Windows 10 | 64,32 / 12,22 | 5,2635 |
| Windows 10 (avec liste blanche) | 42,58 / 12,22 | 3,4845 |

@keawade J'avais 26,48 s pour installer votre projet à partir d'un cache propre et 13,58 s pour l'installer avec le cache.

Je crache juste ici, j'utilise Yarn.cmd du programme d'installation MSI et il semble que vous utilisiez Yarn installé à partir de NPM. Je me demande s'il y a peut-être un écart entre eux?

@nozzlegear Bien que cela soit possible, je pense que c'est moins probable que cela soit dû à des connexions Internet différentes.

Nous devons éliminer le réseau de cela.
Actuellement, je peux tester ce dépôt sur un dernier Windows 10 avec la fonctionnalité «Linux sur Windows» activée.
L'installation via CMD et Bash avec des caches principaux prend environ 27 à 29 secondes sur un processeur i7 à 2 cœurs.

@keawade , pouvez-vous exécuter le même test avec node_modules supprimé mais caches en place?

Je ne peux pas encore installer un deuxième système d'exploitation sur l'appareil que je possède.
Quelqu'un peut-il vérifier si l'exécution de Windows et Linux dans une boîte virtuelle donne des résultats différents?

J'ai construit le maître actuel avec des horodatages https://github.com/yarnpkg/yarn/releases/download/v0.21.0-pre/yarn-0.21.0-0.js

Pouvez-vous l'utiliser pour l'installation avec le drapeau --verbose ?

Par exemple

node /Users/bestander/work/yarn/artifacts/yarn-0.21.0-0.js install --verbose

Il devrait donner des horodatages à toutes les opérations FS

Données sans nettoyage des caches

_Remarque: ces données sont enregistrées sur un système à double démarrage. Tout le matériel est identique pour ces tests.

| OS | Temps moyen | Normalisé |
| ----------------------------- | ---------- | -------- ---- |
| Linux Mint | 5.598s | 1,00000 |
| Windows 10 (avec liste blanche) | 12.119s | 2,16488 |
| Windows 10 (sans liste blanche) | 31,578s | 5,64094 |

_Avg Time est la moyenne sur un ensemble de 10 tests_

Données brutes Linux Mint

[5.47, 5.40, 5.84, 5.96, 5.55, 5.48, 5.40, 5.57, 5.81, 5.50]

Données brutes Windows 10

Avec liste blanche

[11.91, 11.87, 11.88, 12.07, 11.81, 12.02, 12.39, 12.49, 12.28, 12.47]

Sans liste blanche

[30.85, 31.52, 31.39, 31.46, 31.14, 31.41, 34.24, 31.09, 31.40, 31.28]

Méthodologie

J'ai utilisé ce script PowerShell pour générer toutes les données affichées ici. Le script clone ce dépôt et exécute 10 itérations de la commande yarn , en supprimant node_modules après chaque itération.

@bestander , j'ai mis à jour le post précédent avec les données Windows.

Super, merci pour plus de données.
Pouvez-vous essayer la version --verbose avec yarn.js avec des horodatages pour les deux OS?
Cela nous donnerait une bonne idée de l'endroit où le temps est passé.

Ouf, c'est beaucoup de journalisation! Voulez-vous 10 exécutions pour chaque combinaison OS / liste blanche ou une pour chaque combinaison est-elle suffisante?

@bestander Ici vous allez! Un de chaque.

Note latérale: il s'avère que si vous essayez de télécharger ~ 30 Mo de texte brut dans une seule collection essentielle, vous obtenez une erreur nginx 405. 😆

~ Linux Mint ~
~ Windows 10 avec exclusions et avec clean ~
~ Windows 10 avec exclusions et sans _clean_ ~
~ Windows 10 avec propre et sans _exclusions_ ~
~ Windows 10 sans _exclusions_ et _ sans_ nettoyage ~

VerboseLogs.tar.gz

EDIT: Suppression de gists et téléchargement des fichiers compressés.

Il s'avère que si vous essayez de télécharger ~ 30 Mo de texte brut dans une seule collection essentielle, vous obtenez une erreur nginx 405. 😆

Vous pouvez compresser les fichiers (bzip2 ou 7-Zip) et les joindre ici ... Le texte brut se compresse très bien :)

@ Daniel15 Bon point, voici les fichiers compressés: VerboseLogs.tar.gz

1 course serait bien :)

J'ai comparé LinuxMint.txt à Windows10NoClean.txt

Linux:

• la phase de liaison commence à 1,156 secondes
• tous les dossiers à l'intérieur de node_modules créés à 1.968
• dernier fichier copié à 3,873 secondes
• les builds sont terminés en 3 secondes supplémentaires

les fenêtres

• la phase de liaison commence à 2,779 secondes
• tous les dossiers dans node_modules créés en 4.83
• dernier fichier copié à 32.853
• les builds sont terminés en 3 secondes supplémentaires

Évidemment, la journalisation détaillée affecte le temps d'exécution sous Windows (12 -> 35 secondes) mais pas sous Linux (mêmes 6 secondes).

D'après les benchmarks que j'ai trouvés sur Internet, Linux EXT3 FS surpasse généralement NTFS lorsque beaucoup de fichiers sont copiés.
Je me demande si c'est la limite à laquelle nous devons faire face.

@keawade , les vitesses sont-elles différentes lors de l'utilisation de npm @ 3 sous Windows et Linux?

Quelques idées:

• Windows peut être mauvais pour la copie simultanée, nous copions les fichiers dans 4 threads. Peut-être le faire avec un seul thread?
• Peut-être utiliser le wrapper robocopy dans Windows https://github.com/mikeobrien/node-robocopy
• nous utilisons readstream.pipe.writestream pour copier des fichiers, c'est peut-être inefficace sous Windows

Si vous êtes impatient d'expérimenter, remplacez 4 par 1 dans https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L322 et voyez si la copie à un seul thread devient plus rapide sous Windows

Tests de filetage

À la demande de yarnpkg/yarn et modifié la ligne 322 de src/util/fs.js , en remplaçant le 4 par un 1 . J'ai ensuite utilisé yarn run build pour construire le projet et j'ai exécuté 10 tests avec cette construction en utilisant le yarn.cmd qui a été compilé par la construction. Voici les résultats.

| | Temps moyen | Normalisé |
| ---------------------------- | ---------- | --------- --- |
| Windows 10 (avec liste blanche) | 12.119s | 1,00000 |
| Fil à copie unique | 16.927s | 1,39673 |
| Fil de copie unique + Nettoyer | 42.268s | 3.48775 |

_Avg Time est la moyenne sur un ensemble de 10 tests_

Il semble que l'utilisation d'un seul thread pour copier les fichiers entraîne des temps d'installation légèrement plus lents.

Données brutes

Windows 10 (avec liste blanche)

Ces données proviennent d'un test précédent

Fil de copie unique

[15.72, 17.43, 15.16, 17.21, 17.83, 17.47, 16.68, 16.58, 16.93, 18.26]

Fil de copie unique + Nettoyer

[37.68, 40.10, 43.20, 46.18, 40.84, 40.58, 39.69, 47.93, 42.45, 44.03]

Merci, @keawade.
Pouvez-vous vérifier mon hypothèse selon laquelle NTFS pourrait être plus lent à copier un grand nombre de fichiers que Linux FS?

Mesurez la copie via le terminal entièrement installé node_modules vers un autre emplacement à la fois dans Linux Mint et Windows 10, s'il vous plaît.

Il est également nécessaire de tester la copie à l'aide de robocopy avec l'option /mt (copies multi-thread)

J'aimerais également signaler un bogue éventuellement signalé, dans lequel chaque yarn add ou yarn remove prend environ 30 à 40 minutes. Il copie à nouveau TOUTES les dépendances, et comme je suis sous Windows, cela prend beaucoup de temps. Voir le problème lié:

https://github.com/yarnpkg/yarn/issues/2460

@kumarharsh # 2458 Il m'a fallu 28 secondes pour terminer l'installation.

Je dois également mentionner que n'oubliez pas de mettre également en liste blanche les dossiers du projet, pas seulement le cache.

Copier les tests

J'ai utilisé ce script pour exécuter 10 itérations de copies sur Linux Mint et Windows 10. J'ai copié ce dépôt après avoir exécuté yarn dans le répertoire. Ce sont mes résultats.

| OS | Temps moyen | Normalisé |
| ------------ | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35.14085 |

Ce décalage horaire est fou. Ces copies ont été effectuées en copiant des fichiers d'un emplacement à un autre sur _le même SSD_.

Données brutes

Linux Mint

TotalMilliseconds
-----------------
        1515.3961
        1513.9469
        1540.3275
        1527.2777
        1514.6029
        1521.3711
        1512.0628
        1547.8331
        1518.1499
        1563.6521

Windows 10

TotalMilliseconds
-----------------
       55729.4968
       55915.5972
       53427.5155
       51624.6760
       52191.4177
       53556.4542
       53562.5533
       53527.9015
       53610.6127
       53616.9302

Je n'ai pas le temps pour le moment de tester robocopy mais je peux obtenir ces données ce soir après le travail.

Test de Robocopy

J'ai utilisé ce script pour exécuter 10 itérations de copies sur Linux Mint et Windows 10. J'ai copié ce dépôt après avoir exécuté yarn dans le répertoire. Ce sont mes résultats.

| OS | Temps moyen | Normalisé |
| ----------------------- | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

Robocopy a légèrement moins bien fonctionné qu'une copie ordinaire.

Données brutes

Les valeurs Linux Mint et Windows 10 proviennent des tests précédents

TotalMilliseconds
-----------------
       56935.3304
       58234.8084
       57838.7956
       56731.7850
       58380.1805
       58097.6040
       59161.0365
       59062.9404
       58363.5527
       58091.4234

@keawade , pouvez-vous vérifier que l'indexation des fichiers et Defender n'interfèrent pas avec la copie?
Afaik il peut être impliqué même pour une commande cp.

Vérifiez ce qui est actif dans le Gestionnaire des tâches lorsque la copie est terminée.
Et peut-être simplement désactiver ces services pour un test

Indexation et tests Defender

J'ai effectué des tests dans les conditions suivantes:

• Avec Windows Defender désactivé
• Avec le service d'indexation Windows désactivé
• Avec _both_ désactivé Windows Defender et le service d'indexation Windows
• Avec _les deux_ désactivés Windows Defender et le service d'indexation Windows _et_ nettoyage du cache Yarn

Pour désactiver Windows Defender, j'ai désactivé Real-time protection sous le panneau des paramètres de Windows Defender .

Pour désactiver l'indexation Windows, j'ai arrêté le service Windows Search dans le panneau de configuration des

_Remarque: lorsque Windows Defender était activé, aucune exclusion n'était répertoriée_

J'ai utilisé ce script pour exécuter 10 itérations de copies sur Linux Mint et Windows 10. J'ai copié ce dépôt après avoir exécuté yarn dans le répertoire. Ce sont mes résultats.

Sommaire

Il semble que si l'indexation Windows (service de recherche) a un impact sur les opérations de copie et sur Yarn, l'impact le plus important provient de Windows Defender.

Copier

| OS | Temps moyen | Normalisé |
| -------------------------------------------- | ---- -------- | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 (pas de défenseur) | 7301.4307 | 4,78011 |
| Windows 10 (pas d'indexation) | 10307.0794 | 6,74787 |
| Windows 10 (pas de défenseur, pas d'indexation) | 7044.1393 | 4,61166 |
| Windows 10 Robo (pas de défenseur, pas d'indexation) | 10094.8358 | 6,60889 |

Indexation La désactivation complète de l'indexation et de l'antivirus augmente considérablement les performances lors de la copie de fichiers.

Fil

Étant donné que les résultats ci-dessus étaient si prononcés, j'ai pensé que nous pourrions probablement utiliser également des données sur les performances de Yarn dans ces conditions.

J'ai utilisé ce script pour exécuter 10 itérations de yarn à la fois sur Linux Mint et Windows 10. J'ai cloné ce dépôt et exécuté yarn dans le répertoire.

| OS | Temps moyen | Normalisé |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint | 5,5980 | 1,00000 |
| Windows 10 (pas de défenseur) | 16,5450 | 2.95552 |
| Windows 10 (pas d'indexation) | 38,5170 | 6,88049 |
| Windows 10 (pas de défenseur, pas d'indexation) | 16,8490 | 3.00982 |
| Windows 10 Clean (pas de défenseur, pas d'indexation) | 30,7730 | 5,49714 |

Données brutes

Les valeurs de Linux Mint proviennent des tests précédents .

Élément de copie Windows 10

[7053.7702, 7163.6924, 7081.5366, 7131.2731, 6887.5165, 6960.7251, 6999.6528, 7051.1932, 7046.8592, 7065.1741]

Robocopy Windows 10

[10096.4991, 10290.1073, 10350.6061, 9999.0552, 10294.0660, 10024.2568, 9949.6786, 9878.1346, 9801.2121, 10264.7418]

Fil Windows 10

[16.81, 16.23, 16.29, 16.48, 19.03, 16.27, 17.64, 16.64, 16.05, 17.05]

Nettoyage de fil Windows 10

[47.46, 27.83, 28.31, 27.87, 28.90, 30.70, 31.17, 27.97, 28.77, 28.75]

Indexation des fils Windows 10 désactivée

[38.47, 38.63, 38.37, 38.82, 38.05, 38.54, 38.44, 37.90, 39.02, 38.93]

Indexation de copie Windows 10 désactivée

[10222.4855, 10063.3654, 10152.2953, 10151.6155, 10316.7628, 10705.8277, 10199.5391, 10624.1961, 10308.2336, 10326.4731]

Windows 10 Yarn Windows Defender désactivé

[17.03, 16.21, 16.76, 16.43, 16.19, 16.71, 16.23, 16.30, 17.37, 16.22]

Windows 10 Copy Windows Defender désactivé

[7273.9684, 7427.1726, 7409.7312, 7417.4478, 7164.8717, 7427.4655, 7321.0481, 7292.2561, 7159.4540, 7120.8913]

C'est une recherche solide, @keawade , merci pour le partage de toutes les données.
Les données suggèrent que les performances brutes du système de fichiers sont le goulot d'étranglement pour les installations de fils sur Windows.
Je ne suis pas sûr que Yarn puisse faire quoi que ce soit ici à moins qu'il n'y ait une commande de copie intelligente qui contourne la limitation

@keawade merci d'avoir pris tant de peine à compiler ces chiffres! @bestander pourrait-il être ça depuismaman npm ne rencontre pas ces mêmes problèmes lors de la copie (numérisation perpétuelle), peut-être que le fil n'est pas signé? Peut-être que Windows Defender ne fait pas confiance au fil du même niveau que npm. Juste une pensée...

@kumarharsh , nous devrons alors mesurer la différence entre npm et yarn.
Peut-être que npm copie moins de fichiers (le levage de Yarn n'est pas optimisé pour le plus petit arbre node_modules).
Et ce serait formidable si nous pouvions automatiquement ajouter du fil à la liste blanche via le programme d'installation.

peut-être que le fil n'est pas signé? Peut-être que Windows Defender ne fait pas confiance au fil du même niveau que npm.

Je ne pense pas que les scripts puissent être signés (à l'exception des scripts PowerShell qui prennent en charge les signatures Authenticode), donc je ne pense pas que Yarn et npm seraient différents à cet égard. Le programme d'installation de Yarn est signé Authenticode comme celui de npm.

Et ce serait formidable si nous pouvions automatiquement ajouter du fil à la liste blanche via le programme d'installation.

J'ai l'impression que le fait de toucher automatiquement une liste blanche d'analyse de virus entraînerait des scanners de virus marquant le programme d'installation comme un logiciel malveillant. Cela semble être une chose risquée à faire. Cependant, nous pourrions peut-être automatiquement mettre le répertoire sur liste noire dans l'indexeur de recherche.

@keawade J'ai testé robocopy avec les options /E /MT (copies multi-threadées).

| Méthode de copie | Temps moyen |
| ---------------------- | ---------- |
| Copie d'article -Recurse | 20219 |
| Robocopie /E | 26652 |
| Robocopie /E /MT | 9043 |

Données brutes (Windows 10)

Copie d'article -Recurse

[19494.3827, 19471.0148, 19573.9441, 19896.9619, 19413.0355, 20050.4264, 19370.4315, 22959.5867, 20969.9693, 20994.3076]

Robocopie /E

[26522.4862, 26489.6131, 26654.8518, 26910.1073, 26536.042, 26836.0344, 26682.3544, 26408.4497, 26883.7998, 26605.5189]

Robocopie /E /MT

[9274.1374, 9125.6525, 9292.1629, 9014.8979, 8947.7882, 8985.4369, 8742.3616, 8915.4609, 8938.8326, 9200.9616]

Je ne pense pas que les scripts puissent être signés (à l'exception des scripts PowerShell qui prennent en charge les signatures Authenticode), donc je ne pense pas que Yarn et npm seraient différents à cet égard. Le programme d'installation de Yarn est signé Authenticode comme celui de npm.

Semble raisonnable.
Pouvons-nous vérifier cela?
Si vous exécutez npm install , Indexer et Defender apparaissent-ils dans le Gestionnaire des tâches?

NPM Defender et tests d'indexation

J'ai enregistré le temps qu'il a fallu pour exécuter npm install sur ce dépôt dans le même ensemble de conditions que les méthodes de copie Indexing and Defender pour Yarn et Windows.

| OS | Temps moyen | Normalisé |
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint (fil) | 5,5980 | 1,00000 |
| Linux Mint (NPM) | 28,9793 | 5.17672 |
| Windows 10 (pas de défenseur) | 42,6296 | 7,61514 |
| Windows 10 (pas d'indexation) | 53.8791 | 9,62470 |
| Windows 10 (pas de défenseur, pas d'indexation) | 37,9727 | 6,78326 |
| Windows 10 (sans modifications) | 58,5047 | 10,45100 |

Sommaire

Il semble que NPM soit également affecté par Windows Defender.

Données brutes

NPM (Linux Mint)

[29.2353468, 35.6938315, 31.2105951, 30.9298704, 36.5016868, 31.8017671, 30.6387978, 32.3466556, 31.4340427]

NPM (Windows)

[61.2370640, 63.8799427, 62.3602369, 54.0541606, 55.1055082, 59.8259424, 56.7668692, 61.1153600, 54.7739699, 55.9277175]

NPM avec Windows Defender désactivé

[41.1666621, 45.6951565, 43.1979249, 43.9185817, 40.8516877, 42.3445648, 43.5419790, 43.5084263, 45.0731120, 36.9975436]

NPM avec indexation Windows désactivée

[61.1470203, 58.6288137, 52.2553500, 52.4279906, 53.5446943, 54.2839412, 51.1620714, 52.1045756, 51.6424888, 51.5937462]

NPM avec Windows Defender et l'indexation Windows désactivés

[37.1311942, 37.7022530, 38.4630113, 37.5750357, 38.1434941, 37.2711589, 37.2249454, 39.4748951, 38.5522905, 38.1883537]

Je suppose que nous devrons contourner la limitation du ralentissement de Windows au niveau des E / S disque en réduisant le nombre d'opérations d'E / S en général et en éduquant les gens sur l'indexation et Defender.
Le remplacement de la copie par robocopy semble également être une bonne idée.

réduire le nombre d'opérations d'E / S en général

C'est une bonne idée en général, et vous aidera à vous perfectionner partout. Cela pourrait également être très bénéfique pour les personnes qui construisent sur des serveurs avec des disques durs lents.

Dans l'attente d'un PR pour remplacer la tuyauterie de flux fs par une robocopy sous Windows ici .

-- Mettre à jour
Cependant, cela peut ne pas être optimal car copyBulk a une logique supplémentaire comme des exclusions qui peuvent ne pas être traduites en une seule commande robocopy.

Est-ce que quelqu'un sait pourquoi cela arrive pour moi (à chaque fois)?

Pour développer le post:
Sur ma machine Windows - chaque yarn add ou yarn rm recopie tous les modules de nœuds de mon projet, ce qui fait que chaque modification de package.json prend un temps atrocement long. Cette barre de progression pour 160 000 dépendances arrive à chaque fois, et elle rampe comme une tortue bloquée dans un champ pétrolifère. Observez les horaires de l'opération yarn rm paper je viens de faire avant les yarn add - 1000 secondes!

Et annuler l'une de ces opérations add/rm n'est pas possible, car cela gâche le dossier node_modules et tout yarn install / npm install n'installera pas toutes les dépendances - ce qui signifie finalement que je finis par faire un rm -r node_modules/ et tout recommencer. Cette seule raison est suffisamment douloureuse pour m'empêcher d'utiliser l'installation de fil.

Je pense que vous avez mal hissé les node_modules, ce bug va être corrigé dans # 2676

Avec l' introduction par node_modules/ chuté.

Sans liaison fixe:

Done in 167.76s.

real    2m49.633s
user    0m0.229s
sys     0m1.368s

du -sh node_modules/
216M    node_modules/

Avec hardlinking:

Done in 58.07s.

real    0m59.967s
user    0m0.183s
sys     0m1.369s

du -sh node_modules/
189M    node_modules/

Attendez la 0.21.1, il aura le correctif de @kittens au levage.
Devrait être encore plus rapide

Le mercredi 15 février 2017 à 20h04, Hutson Betts [email protected] a écrit:

Avec l' introduction de @bestander https://github.com/bestander de
hardlinking dans # 2620 https://github.com/yarnpkg/yarn/pull/2620 (qui
fonctionne bien dans Windows 7 sans privilèges d'administrateur), mon
temps d'installation et node_modules / size, supprimés.

Sans liaison fixe:

Fait en 167,76s.

réel 2m49.633s
utilisateur 0m0.229s
sys 0m1.368s

du -sh modules_noeud /
216M modules_noeud /

Avec hardlinking:

Fait en 58.07s.

réel 0m59.967s
utilisateur 0m0.183s
sys 0m1.369s

du -sh modules_noeud /
189M modules_noeud /

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/990#issuecomment-280122923 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ACBdWAEghXfPo4bX9mN0hV8l8YaH2rmlks5rc1pigaJpZM4KVwpA
.

Je suis sur Win7 / w Yarn v0.21.3

[3/4] Linking dependencies...
Done in 947.71s. 

J'ai dû attendre ce laps de temps pour ajouter un nouveau package avec yarn add ...
Défenseur off
Indexation désactivée

Avoir un autre AV en cours d'exécution alors suivez simplement ces étapes comme mentionné ci-dessus par @Altiano

Dossier de projet de la liste blanche de AV
White While the Yarn cache directory ((% LocalAppData% Yarn)) from AV

Mettra à jour sur celui-ci

@kuncevic , quel serait le moment d'installation propre du projet?
Quelle est la taille du dossier node_modules dans les fichiers?
Comment cela se compare-t-il à l'installation de npm?

@bestander c'est le même problème avec moi. Tout yarn add ou yarn remove prend le même temps - environ, même après les corrections de levage de

Chaque fois que cela se produit:

1. Tout d'abord, le Fetching packages s'exécute (prend environ 30 secondes):
   
2. Ensuite, la liaison des dépendances s'interrompt pendant environ 1 ou 2 minutes.
   
3. Ensuite, il reprend à l'étape suivante et installe à nouveau (?) 63k fichiers.
   

Comme je l'ai dit, cela se produit chaque fois que je lance yarn add ou yarn remove . Peu importe si la dépendance que j'installe dépend d'une autre dépendance, un simple npm install pour installer une nouvelle dépendance ou mettre à niveau une dépendance existante prend une fraction de ce temps. Les choses se sont améliorées 2x avec les correctifs de levage de

@bestander si vous voulez un cas reproductible, veuillez cloner ce dépôt: https://github.com/kumarharsh/yarn-bug , et exécutez yarn install , puis yarn add react-helmet .

Yarn préserve le déterminisme à chaque fois qu'il exécute add / remove, il doit donc vérifier si une dépendance a été hissée à la racine de node_modules lorsque les dépendances changent.
C'est pourquoi il exécute une phase de liaison complète.

Récupération des dépendances - téléchargez, vous ne pouvez pas l'optimiser.
Première phase de liaison (1561 opérations) - il crée tous les dossiers pour toutes les dépendances.
Deuxième phase de liaison (opérations 63K) - il copie les fichiers du cache vers node_modues.

Yarn optimise les opérations de copie de fichiers en vérifiant si les fichiers sont identiques avant de faire la copie.
Nous pourrions vouloir mieux profiler cette zone et voir si nous pouvons réduire le nombre d'E / S inutiles.
Peut-être que sur Windows, la copie serait plus rapide que la vérification?

Qu'en est-il de npm, à quelle vitesse il s'installe correctement?

Une installation propre pour npm ( npm install ) prend 552301.1944ms .
L'installation d'une dépendance supplémentaire ( npm install weird ) prend 57023.7593ms . (La plupart de ce temps est gaspillé en paperjs essayant d'installer canvas en tant que dep - mais ce temps serait commun pour npm et yarn)

Une installation propre pour le fil ( yarn install ) prend 612698.4915ms .
L'installation d'une dépendance supplémentaire ( yarn add weird ) prend 495633.0307ms .

npm version 3.10.9
yarn version 0.21.3

@bestander @kumarharsh Yarn yarn add ) pour être beaucoup plus rapide simplement en mettant à jour le nœud.

L'utilisation de l'opération de copie de fichiers Windows est un peu plus rapide que l'utilisation de l'API de nœud pour copier des fichiers également (voir # 2960 pour un PR potentiel) et optimiserait un peu yarn install mais je ne sais pas si cela s'égaliserait avec npm (n'a pas testé)

Juste mis à jour vers 7.8.0

nvm install 7.8.0
npm install npm -g (came with 4.4.4)
nvm use 7.8.0
`git clone https://github.com/angular/material2`
cd material2
yarn install - Done in 210.22s.
rimraf node_modules
yarn install - Done in 180.66s.
rimraf node_modules
yarn install - Done in 181.11s.

Cependant en faisant yarn add rimraf on l'a fait en 20.52s. mais pourquoi yarn install après avoir supprimé node_modules prend autant de temps?

ps

rimraf node_modules
npm install - Done in 332.4s
rimraf node_modules
npm install - Done in 402s
rimraf node_modules
npm install - Done in 489.6s

@kuncevic C'est bien de voir que la mise à jour du nœud fonctionne pour yarn add :)

En ce qui concerne les node_modules vides, une bonne chose à faire est de mesurer combien est dû au fil et combien est dû au FileSystem, au disque dur et à l'antivirus.
Ce que j'ai fait pour tester cela, c'était de copier le node_module complet (tel que généré par yarn, pas npm) de material2 quelque part dans le cache de yarn:

for /f "delims=" %i in ('yarn cache dir') do set yarncachedir=%i
xcopy /E /Y /I /Q node_modules %yarncachedir%\x-temp

Et puis pour chaque test, j'ai nettoyé node_modules et exécuté soit yarn install , npm install ou un xcopy du dossier précédemment créé:

rd node_modules /s /q
powershell -Command "Measure-Command { xcopy /E /Y /I /Q %yarncachedir%\x-temp node_modules}"

Et a pris le nombre total de secondes.

Résultats

Voici les résultats sur 3 PC

• 🏠 PC domestique: Samsung 950 Pro NVMe, ESET Nod32
• 🏢 PC de travail: Samsung 850 EVO SATA, TrendMicro OfficeScan que je ne peux pas désactiver
• 🍎 MacBook pro: version 2015, sur macOS, pas d'anti virus

|| yarn 🏠 | npm 🏠 | xcopy 🏠 | yarn 🏢 | npm 🏢 | xcopy 🏢 | yarn 🍎 | npm 🍎
| - | - | - | - | - | - | - | - | -
| AV désactivé | 34s | 90 ans | 23 ans | - | - | - | 32 ans | 92s
| AV Exclure le cache et le code | 38s | 104s | 29s | - | - | - | - | -
| Av Exclure le cache uniquement | 43s | - | 31s | - | - | - | - | -
| Av complet | 48s | 122s | 100s | 274s | 236s | - | -

Chaque fois que l'AV était activé, il dépassait le graphique du processeur pendant yarn install ou xcopy (Sur mon PC domestique, 30% du CPU total a été pris au maximum, mais sur mon PC de travail, il remplit un noyau pour xcopy & tous mes noyaux pour le fil)
xcopy est plus lent sur mon PC de travail que le fil, je suppose qu'il ne copie pas les fichiers en parallèle alors que le fil le fait (cela ne devrait pas avoir d'importance pour les opérations liées aux IO, mais AV en fait une opération liée au processeur combattre tant de bêtises 😄)

En conclusion

• yarn est plus rapide que npm et peut même être plus rapide que xcopy quand AV rend la copie de fichier liée au processeur
• Windows sur un bon SSD n'est pas vraiment plus lent qu'un MacBook Pro 2015 (qui a déjà un bon SSD) même s'il est difficile de comparer car pas exactement les mêmes packages installés, et tous les scripts de post-installation ne font pas la même chose
• Certains changements pourraient être apportés à yarn pour éviter cela (liaison symbolique des fichiers?) Mais essentiellement gérer beaucoup de petits fichiers est lent
• Sur Windows AV peut le ralentir , le mien ajoute 30% lorsqu'il est activé dans les dossiers source et dest 😞
• Les AV d'entreprise peuvent être d'une magnitude plus lente que les AV domestiques et tuer suffisamment les performances pour que toute opération de copie soit douloureuse (lorsqu'elle rend l'opération naturellement liée aux E / S liée au processeur) 😡

Ajouter npm, les dossiers de cache de fil et node.exe à la liste d'exclusion de Defender serait suffisant, bien sûr, tout cela ne peut pas être dans des dossiers indexés. Maintenant, l'ajout de fil / rm prend 7 secondes

Merci à tous, une optimisation significative pour Windows a atterri en 0.24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

@vbfox Pouvez-vous s'il vous plaît ajouter des numéros de version pour npm et yarn dans votre benchmark?

c'est encore une merde pour MacOSX

Je rencontre encore des temps d'installation fous. yarn add semble installer et lier tout (tous les éléments dans package.json , ~ 30k dépendances) tout le temps.

Versions Linux:

$ yarn -v
1.3.2
$ node -v
v8.9.3

Versions Windows:

> conemu-cyg-64.exe --version
ConEmu cygwin/msys connector version 1.2.2
> wslbridge.exe --version
wslbridge 0.2.3
> Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ProductName, CurrentMajorVersionNumber, CurrentMinorVersionNumber, ReleaseId, CurrentBuild, CurrentBuildNumber, BuildLabEx


ProductName               : Windows 10 Pro Insider Preview
CurrentMajorVersionNumber : 10
CurrentMinorVersionNumber : 0
ReleaseId                 : 1709
CurrentBuild              : 17025
CurrentBuildNumber        : 17025
BuildLabEx                : 17025.1000.amd64fre.rs_prerelease.171020-1626

J'ai deux questions (et demie):

1. Quelle est la solution acceptée au problème dans ce fil? Était-ce # 3234 ou peaufiner Windows Defender?

   • Si la solution était de peaufiner Windows Defender, existe-t-il un aperçu complet de ce qu'il faut faire quelque part?

2. Mon problème est-il réellement lié à ce fil ou dois-je en créer un nouveau?

Merci d'avoir soulevé un nouveau problème, j'y répondrai

Cela fait presque une heure maintenant et j'attends cette commande pour terminer le processus. J'ai suivi les points ci-dessus mentionnés par @Altiano mais rien ne fonctionne

avons-nous une alternative pour cela? comme puis-je utiliser npm i -g . est-ce qu'il agira de la même manière ou je devrai faire quelques changements car ce code utilise yarn workspace

Donc finalement, après avoir lutté pendant 2-3 heures, j'ai dû utiliser npm i -g . au lieu de yarn global add file:. . npm a fonctionné comme un charme