Yarn: Benötigen Sie eine große Optimierung für Windows

+1

Hallo @OshotOkill! Danke, dass du Yarn ausprobiert hast. Verwenden Sie Cygwin oder WSL ("Bash unter Ubuntu unter Windows")? Beide haben bekanntermaßen eine ziemlich schlechte Festplatten-E / A-Leistung.

Außerdem verfügt React Native über eine große Anzahl von Dateien, sodass das Kopieren in node_modules ziemlich langsam ist und die Festplatten-E / A für viele kleine Dateien unter Windows im Allgemeinen langsamer ist als Mac OS (das selbst langsamer als Linux ext4 ist). Wir haben die Aufgabe, mit Hardlinks (# 499) zu experimentieren, die die Leistung in diesem Szenario verbessern sollen.

Kein Cache und gleiche Netzwerkumgebung

Die Hauptverbesserung bei Yarn besteht darin, dass Sie einen warmen Cache haben (dh nachdem Sie ein Paket mindestens einmal installiert haben), aber bei React Native ist die große Anzahl von Dateien auch eine Ursache für die Langsamkeit.

@ Daniel15 Nein, ich verwende weder Cygwin / MinGW / MSYS2 noch WSL (letzteres schlägt aufgrund eines knotigen Fehlers fehl).

Nach Ihrer Beschreibung kann ich davon ausgehen, dass das Problem durch das Dateisystem (NTFS) verursacht wird, oder? Selbst wenn ein warmer Cache vorhanden ist, läuft der Kopiervorgang immer noch viel langsamer als unter MacOS.

Ich hoffe, die Entwicklerteams können so schnell wie möglich eine Lösung finden. Vielen Dank.

Ich sehe das gleiche.

Installieren, Node_Module löschen, installieren

MacBookPro benötigt 17 Sekunden, mein Windows-Computer 122 Sekunden.

Jemand wies darauf hin, dass dies möglicherweise mit dem kontinuierlichen Scannen von node_modules durch Antivirensoftware und dem globalen Garncache zusammenhängt. Können Sie versuchen, es für diese Ordner zu deaktivieren?

@cpojer Ich denke, sie haben Recht. Ich habe keine Antivirensoftware auf meinem Computer außer dem vorinstallierten Windows Defender. Daher habe ich das Scannen des globalen Cache-Ordners und meines Projektordners verboten und einige Tests durchgeführt:

Standard: 128.08s

Kein Scannen des Cache-Ordners: 104.43s

Kein Scannen des Projektordners: 78.28s

Kein Scannen des Cache-Ordners und des Projektordners: 53.48s

Obwohl es für 10+ s langsamer als der Mac ist, hat es einen deutlichen Schub.

Dies sollte aus den offiziellen Dokumenten, die ich denke, informiert werden.

Jemand wies darauf hin, dass dies möglicherweise mit dem kontinuierlichen Scannen von node_modules durch Antivirensoftware und dem globalen Garncache zusammenhängt.

Guter Fang! Ich habe das total vergessen, da ich bereits c:\src Whitelist auf meinen Computern habe.

@OshotOkill - Möchten Sie eine Pull-Anfrage senden, die der Website in den Windows-Installationsanweisungen einen Hinweis zu Antiviren-Apps hinzufügt? Hier ist die Datei, die Sie bearbeiten müssen: https://github.com/yarnpkg/website/blob/master/en/docs/_installations/windows.md (Sie können sie direkt auf Github bearbeiten). Es wäre dankbar 😄

Ich war nicht so akribisch wie @OshotOkill , aber ich habe Ausnahmen für meine Quelle und meinen Knoteninstallationsordner hinzugefügt und dann die Binärdateien für Garn, npm und Knoten speziell ausgenommen. Jetzt beträgt meine Neuinstallationszeit unter Windows von 122 Sekunden auf 50 Sekunden .

@ Daniel15 PR ist fertig. Entschuldigen Sie mein schlechtes Englisch.

PR wurde zusammengeführt. Schließen Sie dieses Problem.

Dies ist unter Windows immer noch schmerzhaft langsam und deaktiviert sogar Antivirus und Windows Defender. Ich denke nicht, dass es nur ein Umweltproblem ist (wie diese Antivirenlösung), aber es sieht so aus, als würde Garn versuchen, alle Dateien 1 zu 1 zu kopieren, selbst wenn Sie eine nicht verwandte Abhängigkeit installieren.

Warum nicht einfach die Dateien löschen / kopieren, die geändert werden müssen? Wenn ich webpack installiert hatte und bei der Installation von rimraf nicht geändert wurde, sollte es nicht erneut aus dem Cache in den lokalen Ordner node_modules kopiert werden müssen.

Ich habe auch dazu einen StackOverflow-Artikel erstellt: http://stackoverflow.com/questions/40566222/yarn-5x-slower-on-windows

Übrigens habe ich in meinen (doppelt gebooteten) Ubuntu-Benchmarks dasselbe NTFS-Laufwerk verwendet, auf dem Windows normalerweise ausgeführt wird. und dort ist es immer noch schnell.

Durch das Hinzufügen von node.exe zu Windows Defender-Ausschlüssen konnte ich die Leistung erheblich steigern.

Ich werde das auf jeden Fall ausprobieren!

Es schien die Geschwindigkeit etwas zu verbessern 212 -> 170 Sekunden
Es scheint also zu helfen, aber es könnte noch verbessert werden, da es immer noch mehr als dreimal langsamer ist als unter Linux

Ein weiteres Problem, das mir aufgefallen ist: Der Indizierungsdienst unter Windows versucht, jede Datei in node_modules zu indizieren.
Ich brauche es überhaupt nicht wirklich, also habe ich es deaktiviert http://www.softwareok.com/?seite=faq-Windows-10&faq=53 und einen weiteren Leistungsschub erhalten.

Mein Fenster ist nicht so eingestellt, dass es den betreffenden Pfad indiziert, sodass das Problem immer noch nicht behoben wird.

Zusammenfassend gibt es also vier Möglichkeiten, die Leistung zu verbessern:

• Whitelist-Projektordner von AV
• Während das Garn-Cache-Verzeichnis ((% LocalAppData% Yarn)) von AV
• Hinzufügen von node.exe zu Windows Defender-Ausschlüssen
• Deaktivieren des Indexdienstes unter Windows im Ordner node_modules

@Altiano ja, aber es reicht immer noch nicht aus, um die Leistung auch nur in der Nähe von Mac / Linux zu erreichen

Scheint etwas skizzenhaft, dass Sie AV oder Indizierung in Verzeichnissen deaktivieren müssten, um Garn so schnell oder schneller als npm zu machen. Schließlich müssen Sie dies nicht für npm tun. Ich habe mich für Garn entschieden, weil es schnell war und die Offline-Installationen das Codieren ohne Netzwerkverbindung plausibel machten. Gibt es keine Möglichkeit, die Verknüpfung zu optimieren?

Nach einigen Problemen, die sich hier beziehen, und den obigen Kommentaren möchte ich dieses Problem erneut öffnen, um einige andere Lösungen zu finden.

Persönlich empfehle ich, die Hardwarekonfigurationen Ihres Testgeräts aufzulisten und einige verwandte Bilder hochzuladen. Es könnte viele andere irrelevante Elemente geben, die einen großen Unterschied zwischen Plattformen und nicht Garn selbst ausmachen, dh die Benchmark-Leistung der SSD auf einem MacBook ist normalerweise viel besser als auf einem Windows-Computer.

@OshotOkill Wie ich bereits sagte, habe ich unter Windows im Vergleich zu Linux eine erzielt , da Indizes und Windows Defender für die entsprechenden Verzeichnisse auf demselben regulären PC auf demselben _ntfs_-Laufwerk deaktiviert waren. Dass es selbst unter ntfs unter Linux viel schneller geht, sagt meiner Meinung nach viel aus.

Kommen wir zum Grund dafür.
Könnte es sein, dass NTFS bei einer großen Anzahl von Dateien, die während der Installation verschoben werden, langsamer arbeitet?

Kann jemand eine Möglichkeit teilen, dies auf einer einzelnen Maschine zu reproduzieren?
Beispielsweise dauert eine bestimmte package.json, die auf einem Windows-Laptop installiert ist, X Sekunden, läuft jedoch in VirtualBox Ubuntu X-20% Sekunden.

@amcsi @bestander Wie so oft sind EXT4 / XFS beim Kopieren großer Mengen kleiner Dateien schneller. NTFS ist jedoch nicht viel langsamer. Ich habe gerade den Cache gesäubert und erneut mit der neuesten Version von Yarn and Node (0.19.1 & 7.5.0) getestet:

Das Ergebnis kommt einem MacBook bei der Installation von react-native . Ich habe lediglich die zugehörigen Ordner und den Node.exe-Prozess auf die Whitelist gesetzt.

Ich hatte dieses Problem selbst, bis ich die Prozesse node.exe und yarn.exe in Windows Defender zusammen mit meinem Projektverzeichnis auf die Whitelist gesetzt habe. Ich habe die Suchindizierung überhaupt nicht deaktiviert und das Garn-Cache-Verzeichnis nicht auf die Whitelist gesetzt. Die Installationszeiten stiegen von mehr als 190 Sekunden bei einem mittelgroßen Projekt auf etwa 25 Sekunden bei einem sauberen Cache. Mein Ubuntu-Rechner ist nur ein bisschen schneller, aber nur um 5-10 Sekunden.

Hardwarekonfiguration:
512 GB SSD
12 GB RAM
AMD FX-8350 8-Core-CPU bei 4,01 GHz
Windows 10 64-Bit, Build 14986.

Ich habe gerade ein paar schnelle Tests auf meinem eigenen System durchgeführt. Ich habe Linux Mint und Windows 10 Dual von derselben SSD gebootet. Ich habe meinen Garncache gesäubert, node_modules gelöscht und yarn für dieses Vue-Projekt ausgeführt .

Linux Mint: _12.22s_

Windows 10 (keine weiße Liste): _64.32s_

Windows 10 (mit weißer Auflistung): _42.58s_

Dies waren die Windows Defender-Ausschlüsse, die ich aktiv hatte:

Während White Listing einen signifikanten Effekt zu haben schien, kam es der Geschwindigkeit unter Linux immer noch nicht nahe.

EDIT: Für @bestander sind hier meine normalisierten Daten:

| Betriebssystem | Berechnung | Normalisierte Daten |
| --- | --- | --- |
| Linux Mint | 12.22 / 12.22 | 1 |
| Windows 10 | 64,32 / 12,22 | 5,2635 |
| Windows 10 (mit weißer Auflistung) | 42,58 / 12,22 | 3,4845 |

@keawade Ich hatte 26,48 Sekunden Zeit, um Ihr Projekt aus einem sauberen Cache zu installieren, und 13,58 Sekunden, um es mit dem Cache zu installieren.

Ich verwende hier nur Yarn.cmd aus dem MSI-Installationsprogramm und es sieht so aus, als würden Sie Yarn verwenden, das von NPM installiert wurde. Ich frage mich, ob es vielleicht eine Diskrepanz zwischen ihnen gibt.

@nozzlegear Das ist zwar möglich, aber meiner Meinung nach weniger wahrscheinlich als aufgrund unterschiedlicher Internetverbindungen.

Wir müssen das Netzwerk daraus entfernen.
Derzeit kann ich dieses Repo unter Windows 10 mit aktivierter Funktion "Linux unter Windows" testen.
Sowohl über CMD als auch über Bash mit Prime-Caches dauert die Installation auf einem 2-Core-i7-Prozessor etwa 27 bis 29 Sekunden.

@keawade , können Sie denselben Test ausführen, bei dem node_modules entfernt, aber die Caches vorhanden sind?

Ich kann noch kein zweites Betriebssystem auf dem Gerät installieren, das ich habe.
Kann jemand überprüfen, ob das Ausführen von Windows und Linux in einer virtuellen Box zu unterschiedlichen Ergebnissen führt?

Ich habe den aktuellen Master mit Zeitstempeln https://github.com/yarnpkg/yarn/releases/download/v0.21.0-pre/yarn-0.21.0-0.js erstellt

Können Sie es für die Installation mit dem Flag --verbose verwenden?

Z.B

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

Es sollte Zeitstempel für alle FS-Operationen geben

Daten ohne Bereinigung der Caches

_Hinweis: Diese Daten werden auf einem System mit zwei Starts aufgezeichnet. Die gesamte Hardware ist für diese Tests identisch.

| Betriebssystem | Durchschn. Zeit | Normalisiert |
| ----------------------------- | ---------- | -------- ---- |
| Linux Mint | 5.598s | 1,00000 |
| Windows 10 (mit weißer Liste) | 12.119s | 2.16488 |
| Windows 10 (ohne weiße Liste) | 31.578s | 5.64094 |

_Avg Time ist der Durchschnitt über einen Satz von 10 Tests_

Rohe Linux Mint-Daten

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

Rohe Windows 10-Daten

Mit White Listing

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

Ohne White Listing

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

Methodik

Ich habe dieses PowerShell-Skript verwendet , um alle hier gezeigten Daten zu generieren. Das Skript klont dieses Repo und führt 10 Iterationen des Befehls yarn , wobei nach jeder Iteration node_modules gelöscht wird.

@bestander , ich habe den vorherigen Beitrag mit den Windows-Daten aktualisiert.

Super, danke für mehr Daten.
Können Sie die --verbose-Version mit yarn.js mit Zeitstempeln für beide Betriebssysteme ausprobieren?
Es würde uns eine gute Idee geben, wo Zeit verbracht wird.

Puh, das ist viel Protokollierung! Möchten Sie 10 Läufe für jede Kombination aus Betriebssystem und weißer Liste oder ist einer für jede ausreichend?

@bestander Los geht's! Einer von jedem.

Randnotiz: Wenn Sie versuchen, ~ 30 MB Rohtext in eine einzelne Kernsammlung hochzuladen, wird ein Nginx 405-Fehler angezeigt. 😆

~ Linux Mint ~
~ Windows 10 mit Ausschlüssen und mit sauberen ~
~ Windows 10 mit Ausschlüssen und ohne _clean_ ~
~ Windows 10 mit sauber und ohne _Ausschlüsse_ ~
~ Windows 10 ohne _Ausschlüsse_ und _ohne_ sauber ~

VerboseLogs.tar.gz

BEARBEITEN: Entfernen der Kernel und Hochladen der komprimierten Dateien.

Wenn Sie versuchen, ~ 30 MB Rohtext in eine einzelne Sammlung hochzuladen, wird ein Nginx 405-Fehler angezeigt. 😆

Sie können die Dateien (bzip2 oder 7-Zip) komprimieren und hier anhängen ... Nur-Text-Komprimierungen sehr gut :)

@ Daniel15 Guter Punkt, hier sind die komprimierten Dateien: VerboseLogs.tar.gz

1 Lauf wäre in Ordnung :)

Ich habe LinuxMint.txt mit Windows10NoClean.txt verglichen

Linux:

• Die Verbindungsphase beginnt bei 1,156 Sekunden
• Alle Ordner in node_modules wurden um 1.968 erstellt
• Letzte kopierte Datei bei 3,873 Sekunden
• Builds sind in weiteren 3 Sekunden fertig

Windows

• Die Verbindungsphase beginnt bei 2,779 Sekunden
• Alle Ordner in node_modules wurden um 4.83 erstellt
• letzte bei 32.853 kopierte Datei
• Builds sind in weiteren 3 Sekunden fertig

Offensichtlich beeinflusst die ausführliche Protokollierung die Ausführungszeit unter Windows (12 -> 35 Sekunden), nicht jedoch unter Linux (dieselben 6 Sekunden).

Von den Benchmarks, die ich im Internet gefunden habe, übertrifft Linux EXT3 FS normalerweise NTFS, wenn viele Dateien kopiert werden.
Ich frage mich, ob dies die Grenze ist, der wir uns stellen müssen.

@keawade , unterscheiden sich die Geschwindigkeiten bei Verwendung von npm @ 3 unter Windows und Linux?

Ein paar Ideen:

• Windows kann beim gleichzeitigen Kopieren schlecht sein, wir kopieren Dateien in 4 Threads. Vielleicht macht es Single Threaded?
• Verwenden Sie möglicherweise den Robocopy-Wrapper unter Windows https://github.com/mikeobrien/node-robocopy
• Wir verwenden readstream.pipe.writestream, um Dateien zu kopieren. Unter Windows ist dies möglicherweise ineffizient

Wenn Sie experimentieren möchten, ersetzen Sie 4 durch 1 in https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L322 und prüfen Sie, ob Das Kopieren mit einem Thread wird unter Windows schneller

Thread-Tests

Auf Anfrage von yarnpkg/yarn und modifizierte Zeile 322 von src/util/fs.js , wobei ich 4 durch 1 ersetzte. Ich habe dann yarn run build , um das Projekt zu erstellen, und 10 Tests mit diesem Build unter Verwendung der yarn.cmd , die vom Build kompiliert wurden. Das sind die Ergebnisse.

| | Durchschn. Zeit | Normalisiert |
| ---------------------------- | ---------- | --------- --- |
| Windows 10 (mit weißer Liste) | 12.119s | 1,00000 |
| Einzelkopie-Thread | 16.927s | 1,39673 |
| Einzelkopie-Thread + Reinigen | 42.268s | 3,48775 |

_Avg Time ist der Durchschnitt über einen Satz von 10 Tests_

Es sieht so aus, als würde die Verwendung nur eines einzigen Threads zum Kopieren der Dateien zu etwas langsameren Installationszeiten führen.

Rohdaten

Windows 10 (mit weißer Liste)

Diese Daten stammen aus einem früheren Test

Einzelkopie-Thread

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

Einzelkopie-Thread + Reinigen

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

Danke, @keawade.
Können Sie meine Annahme überprüfen, dass NTFS beim Kopieren einer großen Anzahl von Dateien möglicherweise langsamer ist als Linux FS?

Messen Sie bitte das Kopieren über das Terminal mit vollständig installierten node_modules an einen anderen Speicherort in Linux Mint und Windows 10.

Es ist auch erforderlich, die Kopie mithilfe von Robocopy mit der Option /mt (Multithread-Kopien) zu testen.

Ich möchte auch einen möglicherweise gemeldeten Fehler melden, bei dem jedes einzelne yarn add oder yarn remove etwa 30-40 Minuten dauert. Anscheinend werden ALLE Abhängigkeiten erneut kopiert, und da ich unter Windows bin, dauert dies lange. Siehe verknüpfte Ausgabe:

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

@kumarharsh # 2458 Ich habe 28 abzuschließen .

Außerdem muss ich erwähnen, dass Sie nicht vergessen, auch die Projektordner auf die Whitelist zu setzen, nicht nur den Cache.

Kopiertests

Ich habe dieses Skript verwendet , um 10 Iterationen von Kopien unter Linux Mint und Windows 10 auszuführen. Ich habe dieses Repo kopiert, nachdem ich yarn im Verzeichnis ausgeführt habe. Das sind meine Ergebnisse.

| Betriebssystem | Durchschn. Zeit | Normalisiert |
| ------------ | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35.14085 |

Dieser Zeitunterschied ist verrückt. Diese Kopien wurden durchgeführt, indem Dateien von einem Ort zu einem anderen auf derselben SSD kopiert wurden.

Rohdaten

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

Ich habe momentan keine Zeit, die Robokopie zu testen, aber ich kann diese Daten heute Abend nach der Arbeit abrufen.

Robokopietest

Ich habe dieses Skript verwendet , um 10 Iterationen von Kopien unter Linux Mint und Windows 10 auszuführen. Ich habe dieses Repo kopiert, nachdem ich yarn im Verzeichnis ausgeführt habe. Das sind meine Ergebnisse.

| Betriebssystem | Durchschn. Zeit | Normalisiert |
| ----------------------- | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10 (Robocopy) | 58089.7457 | 38.03024 |

Robocopy schnitt etwas schlechter ab als eine normale Kopie.

Rohdaten

Die Linux Mint- und Windows 10-Werte stammen aus den vorherigen Tests

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

@keawade , können Sie überprüfen, ob die Dateiindizierung und Defender die Kopie nicht beeinträchtigen?
Afaik kann es sogar für einen CP-Befehl beteiligt werden.

Überprüfen Sie, was im Task-Manager aktiv ist, wenn der Kopiervorgang abgeschlossen ist.
Und vielleicht schalten Sie diese Dienste einfach für einen Test aus

Indizierungs- und Verteidigertests

Ich habe Tests unter folgenden Bedingungen durchgeführt:

• Mit deaktiviertem Windows Defender
• Mit deaktiviertem Windows-Indizierungsdienst
• Mit _both_ deaktiviertem Windows Defender- und Windows Indexing-Dienst
• Wenn _beides_ Windows Defender und Windows Indexing-Dienst deaktiviert _und_ den Garn-Cache bereinigen

Um Windows Defender zu deaktivieren, habe ich Real-time protection im Windows Defender-Einstellungsfeld deaktiviert.

So deaktivieren Sie Windows - Indizierung, stoppte ich den Windows - Suchdienst in der Systemsteuerung Dienste .

_Hinweis: Wenn Windows Defender aktiviert war, wurden keine Ausschlüsse aufgelistet_

Ich habe dieses Skript verwendet , um 10 Iterationen von Kopien unter Linux Mint und Windows 10 auszuführen. Ich habe dieses Repo kopiert, nachdem ich yarn im Verzeichnis ausgeführt habe. Das sind meine Ergebnisse.

Zusammenfassung

Es sieht so aus, als ob die Windows-Indizierung (Suchdienst) Auswirkungen auf Kopiervorgänge und Garn hat. Die größere Auswirkung kommt jedoch von Windows Defender.

Kopieren

| Betriebssystem | Durchschn. Zeit | Normalisiert |
| ---------------------------------------- | ---- -------- | ------------ |
| Linux Mint | 1527.4620 | 1,00000 |
| Windows 10 (kein Verteidiger) | 7301.4307 | 4.78011 |
| Windows 10 (keine Indizierung) | 10307.0794 | 6.74787 |
| Windows 10 (Kein Verteidiger, keine Indizierung) | 7044.1393 | 4.61166 |
| Windows 10 Robo (Kein Verteidiger, keine Indizierung) | 10094.8358 | 6.60889 |

Indizierung Durch die vollständige Deaktivierung der Indizierung und des Virenschutzes wird die Leistung beim Kopieren von Dateien erheblich gesteigert.

Garn

Da die obigen Ergebnisse so ausgeprägt waren, dachte ich, wir könnten wahrscheinlich auch unter diesen Bedingungen Daten zur Leistung von Yarn verwenden.

Ich habe dieses Skript verwendet , um 10 Iterationen von yarn unter Linux Mint und Windows 10 auszuführen. Ich habe dieses Repo geklont und yarn im Verzeichnis ausgeführt.

| Betriebssystem | Durchschn. Zeit | Normalisiert |
| ----------------------------------------- | --- ------- | ------------ |
| Linux Mint | 5,5980 | 1,00000 |
| Windows 10 (kein Verteidiger) | 16.5450 | 2,95552 |
| Windows 10 (keine Indizierung) | 38.5170 | 6.88049 |
| Windows 10 (Kein Verteidiger, keine Indizierung) | 16.8490 | 3.00982 |
| Windows 10 Clean (Kein Verteidiger, keine Indizierung) | 30.7730 | 5.49714 |

Rohdaten

Die Linux Mint-Werte stammen aus den vorherigen Tests .

Windows 10-Kopierelement

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

Windows 10 Robocopy

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

Windows 10 Garn

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

Windows 10 Garn reinigen

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

Windows 10-Garnindizierung deaktiviert

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

Windows 10-Kopierindizierung deaktiviert

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

Windows 10 Garn Windows Defender deaktiviert

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

Windows 10-Kopie Windows Defender deaktiviert

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

Das ist eine solide Forschung, @keawade , danke, dass Sie alle Daten geteilt haben.
Die Daten legen nahe, dass die Leistung des Rohdateisystems der Engpass bei der Installation von Garn unter Windows ist.
Ich bin nicht sicher, ob Yarn hier etwas tun kann, es sei denn, es gibt einen Smart Copy-Befehl, der die Einschränkung umgeht

@keawade, danke, dass Mühe gegeben hast , diese Zahlen zusammenzustellen! @bestander könnte es sein, dass daMama npm hat beim Kopieren (fortwährendes Scannen) nicht dieselben Probleme. Vielleicht ist das Garn nicht signiert? Könnte sein, dass Windows Defender dem Garn nicht das gleiche Niveau wie npm vertraut. Nur ein Gedanke...

@kumarharsh , dann müssen wir den Unterschied zwischen npm und Garn messen.
Möglicherweise kopiert npm weniger Dateien (das Heben von Yarn ist nicht für den kleinsten Baum von node_modules optimiert).
Und es wäre großartig, wenn wir das Garn automatisch per Installer auf die Whitelist setzen könnten.

Vielleicht ist das Garn nicht signiert? Könnte sein, dass Windows Defender dem Garn nicht das gleiche Niveau wie npm vertraut.

Ich glaube nicht, dass Skripte signiert werden können (mit Ausnahme von PowerShell-Skripten, die Authenticode-Signaturen unterstützen), daher denke ich nicht, dass sich Yarn und npm in dieser Hinsicht unterscheiden würden. Das Installationsprogramm von Yarn ist wie das von npm mit Authenticode signiert.

Und es wäre großartig, wenn wir das Garn automatisch per Installer auf die Whitelist setzen könnten.

Ich habe das Gefühl, dass das automatische Berühren einer Whitelist für das Scannen von Viren dazu führen würde, dass Virenscanner das Installationsprogramm als Malware markieren. Es scheint eine riskante Sache zu sein. Vielleicht könnten wir das Verzeichnis im Suchindexer jedoch automatisch auf die schwarze Liste setzen.

@keawade Ich habe Robocopy mit den Optionen /E /MT (Multithread-Kopien) getestet.

| Kopiermethode | Durchschn. Zeit |
| ---------------------- | ---------- |
| Copy-Item -Recurse | 20219 |
| Robocopy /E | 26652 |
| Robocopy /E /MT | 9043 |

Rohdaten (Windows 10)

Copy-Item -Recurse

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

Robocopy /E

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

Robocopy /E /MT

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

Ich glaube nicht, dass Skripte signiert werden können (mit Ausnahme von PowerShell-Skripten, die Authenticode-Signaturen unterstützen), daher denke ich nicht, dass sich Yarn und npm in dieser Hinsicht unterscheiden würden. Das Installationsprogramm von Yarn ist wie das von npm mit Authenticode signiert.

Klingt vernünftig.
Können wir das noch einmal überprüfen?
Wenn npm install , werden Indexer und Defender im Task-Manager angezeigt?

NPM Defender- und Indizierungstests

Ich habe die Zeit aufgezeichnet, die benötigt wurde, um npm install auf diesem Repo unter denselben Bedingungen wie bei den Indexierungs- und Verteidigungstests für Garn- und Windows-Kopiermethoden auszuführen.

| Betriebssystem | Durchschn. Zeit | Normalisiert |
| ----------------------------------------- | --- ------- | ------------ |
| Linux Mint (Garn) | 5,5980 | 1,00000 |
| Linux Mint (NPM) | 28.9793 | 5.17672 |
| Windows 10 (kein Verteidiger) | 42.6296 | 7.61514 |
| Windows 10 (keine Indizierung) | 53.8791 | 9.62470 |
| Windows 10 (Kein Verteidiger, keine Indizierung) | 37,9727 | 6.78326 |
| Windows 10 (keine Änderungen) | 58.5047 | 10.45100 |

Zusammenfassung

NPM scheint auch von Windows Defender betroffen zu sein.

Rohdaten

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 mit deaktiviertem Windows Defender

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

NPM mit deaktivierter Windows-Indizierung

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

NPM mit deaktiviertem Windows Defender und Windows-Indizierung

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

Ich nehme an, wir müssen die Einschränkung umgehen, dass Windows bei Festplatten-E / A langsamer ist, indem wir die Anzahl der E / A-Vorgänge im Allgemeinen reduzieren und die Benutzer über Indizierung und Defender informieren.
Das Ersetzen einer Kopie durch eine Robokopie scheint ebenfalls eine gute Idee zu sein.

Reduzierung der Anzahl der E / A-Vorgänge im Allgemeinen

Dies ist im Allgemeinen eine gute Idee und hilft bei der Perfektionierung überall. Dies kann auch für Benutzer von Vorteil sein, die auf Servern mit langsamen Festplatten aufbauen.

Wir freuen uns für eine PR - fs zu ersetzen Ströme mit einem Robocopy auf Windows kochend hier .

- Update
Dies ist jedoch möglicherweise nicht optimal, da copyBulk über eine zusätzliche Logik wie Ausschlüsse verfügt, die möglicherweise nicht in einen einzelnen Robocopy-Befehl übersetzt werden.

Weiß jemand, warum das bei mir passiert (jedes Mal)?

So erweitern Sie den Beitrag:
Auf meinem Windows-Computer kopiert jedes einzelne yarn add oder yarn rm alle Knotenmodule in meinem Projekt neu, sodass jede Änderung an package.json unglaublich lange dauert. Dieser Fortschrittsbalken für 160.000 Abhängigkeiten kommt jedes Mal und kriecht wie eine Schildkröte, die auf einem Ölfeld gestrandet ist. Beachten Sie die Zeitabläufe bei der Operation yarn rm paper , die ich gerade vor der Operation yarn add - 1000 Sekunden durchgeführt habe!

Das Abbrechen einer dieser add/rm -Operationen ist nicht möglich, da der Ordner node_modules durcheinander gebracht wird und alle nachfolgenden yarn install / npm install nicht alle Abhängigkeiten installieren - was letztendlich bedeutet dass ich am Ende ein rm -r node_modules/ mache und von vorne anfange. Dieser einzige Grund ist schmerzhaft genug, um mich davon abzuhalten, überhaupt Garn zu installieren.

Ich denke, Sie haben node_modules schlecht gehisst, dieser Fehler wird in # 2676 behoben

Mit der Einführung von Hardlink durch @bestander in # 2620 (was unter Windows 7 ohne Administratorrechte problemlos funktioniert) sanken meine Gesamtinstallationszeiten und die Größe von node_modules/ .

Ohne Hardlink:

Done in 167.76s.

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

du -sh node_modules/
216M    node_modules/

Mit Hardlinking:

Done in 58.07s.

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

du -sh node_modules/
189M    node_modules/

Warten Sie auf 0.21.1, es wird @kittens 'Korrektur für das Heben haben.
Sollte noch schneller sein

Am Mittwoch, den 15. Februar 2017 um 20:04 Uhr schrieb Hutson Betts [email protected] :

Mit @bestander https://github.com/bestander Einführung von
Hardlinking in # 2620 https://github.com/yarnpkg/yarn/pull/2620 (Welche
funktioniert gut in Windows 7 ohne Administratorrechte), meine insgesamt
Installationszeiten und Knotenmodule / Größe wurden gelöscht.

Ohne Hardlink:

Geschehen in 167,76s.

echte 2m49.633s
Benutzer 0m0.229s
sys 0m1.368s

du -sh node_modules /
216M Knotenmodule /

Mit Hardlinking:

Fertig in 58.07s.

echte 0m59.967s
Benutzer 0m0.183s
sys 0m1.369s

du -sh node_modules /
189M Knotenmodule /

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/990#issuecomment-280122923 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/ACBdWAEghXfPo4bX9mN0hV8l8YaH2rmlks5rc1pigaJpZM4KVwpA
.

Ich bin auf Win7 / w Yarn v0.21.3

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

Musste so lange warten, bis ein neues Paket mit yarn add ... hinzugefügt wurde
Verteidiger aus
Indizierung deaktiviert

Lassen Sie ein anderes AV-Gerät laufen. Befolgen Sie daher einfach die oben von @Altiano genannten Schritte

Whitelist-Projektordner von AV
Während das Garn-Cache-Verzeichnis ((% LocalAppData% Yarn)) von AV

Wird auf diesem aktualisiert

@kuncevic , was wäre eine saubere Installationszeit für das Projekt?
Wie groß ist der Ordner node_modules in Dateien?
Wie ist der Vergleich zur npm-Installation?

@bestander das ist das gleiche problem bei mir. Alle yarn add oder yarn remove benötigen die gleiche Zeit - ungefähr auch nach den

Immer wenn dies passiert:

1. Zunächst wird Fetching packages (dauert ca. 30 Sekunden):
   
2. Anschließend wird das Verknüpfen von Abhängigkeiten etwa 1 bis 2 Minuten lang angehalten.
   
3. Dann wird es mit dem nächsten Schritt fortgesetzt und installiert erneut (?) 63k-Dateien.
   

Wie gesagt, dies passiert jedes Mal, wenn ich yarn add oder yarn remove . Es spielt keine Rolle, ob die von mir installierte Abhängigkeit von einer anderen Abhängigkeit abhängt. Ein einfaches npm install zum Installieren einer neuen Abhängigkeit oder zum Aktualisieren einer vorhandenen benötigt einen Bruchteil dieser Zeit. Mit den Korrekturen für das Heben von Zweifache verbessert, aber die benötigte Zeit ist immer noch zu lang.

@bestander Wenn Sie einen reproduzierbaren Fall wünschen, klonen Sie bitte dieses Repo: https://github.com/kumarharsh/yarn-bug und führen Sie yarn install und dann yarn add react-helmet .

Das Garn behält bei jeder Ausführung von Add / Remove den Determinismus bei. Daher muss überprüft werden, ob eine Abhängigkeit an die Wurzel von node_modules angehoben wurde, wenn sich die Abhängigkeiten ändern.
Aus diesem Grund wird die vollständige Verknüpfungsphase ausgeführt.

Abhängigkeiten abrufen - Download, Sie können es nicht optimieren.
Erste Verknüpfungsphase (1561 Operationen) - Es werden alle Ordner für alle Abhängigkeiten erstellt.
Zweite Verknüpfungsphase (63K-Operationen) - Kopiert die Dateien aus dem Cache in die Knotenmodi.

Garn optimiert Dateikopiervorgänge, indem vor dem Kopieren überprüft wird, ob die Dateien identisch sind.
Möglicherweise möchten wir diesen Bereich besser profilieren und prüfen, ob wir die Anzahl unnötiger E / A verringern können.
Vielleicht wäre das Kopieren unter Windows schneller als das Überprüfen?

Was ist mit npm, wie schnell wird es sauber installiert?

Eine Neuinstallation für npm ( npm install ) kostet 552301.1944ms .
Das Installieren einer zusätzlichen Abhängigkeit ( npm install weird ) erfordert 57023.7593ms . (Die meiste Zeit wird in Papieren verschwendet, die versuchen, Leinwand als Dep zu installieren - aber diese Zeit ist sowohl für npm als auch für Garn üblich.)

Eine Neuinstallation für Garn ( yarn install ) kostet 612698.4915ms .
Das Installieren einer zusätzlichen Abhängigkeit ( yarn add weird ) erfordert 495633.0307ms .

npm version 3.10.9
yarn version 0.21.3

@bestander @kumarharsh Yarn optimiert die Dateikopiervorgänge unter Windows aufgrund eines libuv / nodejs-Fehlers (siehe # 2958 für eine mögliche Korrektur im Garncode), der auf Knoten 7.1+ nicht vorhanden ist, nicht, sodass Sie Ihren zweiten Befehl erhalten können ( yarn add ) um viel schneller zu sein, nur durch Aktualisieren des Knotens.

Die Verwendung des Windows-Dateikopiervorgangs ist etwas schneller als die Verwendung der Knoten-API zum Kopieren von Dateien (siehe # 2960 für eine potenzielle PR) und würde yarn install ein wenig optimieren, aber ich weiß nicht, ob dies egalisieren würde npm (nicht getestet)

Gerade auf 7.8.0 aktualisiert

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.

Wenn Sie jedoch yarn add rimraf ausführen, wird dies in 20.52s. erledigt, aber warum yarn install nachdem das Entfernen von node_modules so lange gedauert hat?

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 Schön zu sehen, dass das Aktualisieren des Knotens für yarn add funktioniert :)

In Bezug auf leere node_modules eine gute Sache zu messen, wie viel auf Garn und wie viel auf FileSystem, Festplatte und Anti-Virus zurückzuführen ist.
Um dies zu testen, habe ich die vollständigen node_module (wie von Garn generiert, nicht von npm) von material2 irgendwo im Garncache kopiert:

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

Und dann habe ich für jeden Test node_modules bereinigt und entweder yarn install , npm install oder xcopy aus dem zuvor erstellten Ordner ausgeführt:

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

Und dauerte die gesamten Sekunden.

Ergebnisse

Hier sind die Ergebnisse auf 3 PCs

• 🏠 Heim-PC: Samsung 950 Pro NVMe, ESET Nod32
• 🏢 Arbeits-PC: Samsung 850 EVO SATA, TrendMicro OfficeScan, den ich nicht deaktivieren kann
• 🍎 MacBook Pro: Version 2015, auf Macos, kein Virenschutz

|| yarn 🏠 | npm 🏠 | xcopy 🏠 | yarn 🏢 | npm 🏢 | xcopy 🏢 | yarn 🍎 | npm 🍎
| - | - | - | - | - | - | - | - | - |
| AV deaktiviert | 34s | 90er | 23er | - | - | - | 32er | 92s
| AV Cache & Code ausschließen | 38s | 104s | 29s | - | - | - | - | -
| Av Nur Cache ausschließen | 43s | - | 31s | - | - | - | - | -
| Av voll | 48s | 122s | 32s | 100s | 274s | 236s | - | -

Jedes Mal, wenn AV aktiviert war, wurde das CPU-Diagramm während yarn install oder xcopy (auf meinem Heim-PC wurden maximal 30% der CPU-Gesamtmenge verbraucht, aber auf meinem Arbeits-PC füllte es einen Kern für xcopy & alle meine Kerne für Garn)
xcopy ist auf meinem Arbeits-PC langsamer als Garn, vermute ich, weil es keine parallelen Dateien kopiert, während Garn dies tut (Das sollte für E / A-gebundene Operationen keine Rolle spielen, aber AV macht es zu einer CPU-gebundenen Operation und xcopy wurde nicht geschrieben kämpfe so viel Dummheit 😄)

Abschließend

• yarn ist schneller als npm und kann sogar schneller als xcopy wenn AV die Dateikopie CPU-gebunden macht
• Windows auf einer guten SSD ist nicht wirklich langsamer als ein MacBook Pro 2015 (das bereits eine gute SSD hat), auch wenn es schwer zu vergleichen ist, da nicht genau dieselben Pakete installiert werden und nicht alle Skripte nach der Installation dasselbe tun
• Einige Änderungen könnten am Garn vorgenommen werden, um dies zu umgehen (Symlinking von Dateien?), Aber im Wesentlichen ist das Bewältigen vieler kleiner Dateien langsam
• Unter Windows AV kann es langsamer werden , meins fügt 30% hinzu, wenn es sowohl im Quell- als auch im Zielordner aktiviert ist 😞
• Unternehmens-AVs können eine Größenordnung langsamer sein als Heim-AVs und die Kill-Leistung so weit, dass jeder Kopiervorgang schmerzhaft ist (wenn dadurch die natürlich an die E / A gebundene Operation CPU-gebunden wird) 😡

Das Hinzufügen von npm, Garn-Cache-Ordnern und node.exe zur Ausschlussliste des Verteidigers würde ausreichen, natürlich kann dies alles nicht in indizierten Ordnern sein. Jetzt dauert das Hinzufügen von Garn / rm 7 Sekunden

Vielen Dank an alle, eine signifikante Optimierung für Windows landete in 0.24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

@vbfox Können Sie bitte Versionsnummern für npm und yarn in Ihren Benchmark aufnehmen?

Dies ist immer noch ein Stück Scheiße für MacOSX

Ich habe immer noch verrückte Installationszeiten. yarn add scheint ständig alles zu installieren und zu verknüpfen (alle Elemente in package.json , ~ 30.000 Abhängigkeiten).

Linux-Versionen:

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

Windows-Versionen:

> 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

Ich habe zweieinhalb Fragen:

1. Was ist die akzeptierte Lösung für das Problem in diesem Thread? War es # 3234 oder Windows Defender optimiert?

   • Wenn die Lösung Windows Defender optimiert hat, gibt es eine vollständige Beschreibung, was irgendwo zu tun ist?

2. Bezieht sich mein Problem tatsächlich auf diesen Thread oder sollte ich einen neuen erstellen?

Vielen Dank, dass Sie ein neues Problem angesprochen haben. Ich werde dort antworten

Es ist jetzt fast eine Stunde her und ich warte darauf, dass dieser Befehl den Vorgang beendet. Ich habe die oben genannten Punkte von @Altiano befolgt, aber nichts funktioniert

Haben wir dafür eine Alternative? Wie kann ich npm i -g . Wird es auf die gleiche Weise funktionieren oder ich muss einige Änderungen vornehmen, da dieser Code Garn workspace

Nachdem ich 2-3 Stunden lang gekämpft hatte, musste ich schließlich npm i -g . anstelle von yarn global add file:. . npm wirkte wie ein Zauber