Yarn: Windowsの大きな最適化が必要

作成日 2016年10月13日  ·  80コメント  ·  ソース: yarnpkg/yarn

_feature_をリクエストしますか、それとも_bug_を報告しますか?

特徴

現在の動作は何ですか?

MacOSとWindows間のインストール速度について多くのテストを行いました。 結果によると、糸はWindows用の最適化がはるかに少ないようです。 例: react-nativeのインストールの比較は次のとおりです。


試験機:

  • ThinkPad X1 Carbon 4、1TB PCI-E SSD、16GBメモリ
  • MacBook Air 2014、256GB SSD、4GBメモリ

キャッシュなしで同じネットワーク環境


マックOS

[email protected]1分31秒

2016-10-13 17 52 24

ヤーン@ 0.15.139秒

2016-10-13 17 54 53


ウィンドウズ

[email protected]2分24秒

2

ヤーン@ 0.15.12分19秒

1


したがって、Windowsではnpmよりもyarnの方が有利ではないようです。 誰かがこの外観に直面しましたか?

node.js、yarn、およびオペレーティングシステムのバージョンをお知らせください。
nodejs:6.8.0
糸:0.15.1
OS:Windows 10 14393.321&MacOS 10.12

cat-performance

最も参考になるコメント

@cpojer私は彼らが正しいと思います。 プレインストールされたWindowsDefenderを除いて、マシンにウイルス対策ソフトウェアがないため、グローバルキャッシュフォルダーとプロジェクトフォルダーのスキャンを禁止し、いくつかのテストを行いました。

デフォルト:128.08s

2


キャッシュフォルダのスキャンなし:104.43s

3


プロジェクトフォルダのスキャンなし:78.28s

5


キャッシュフォルダとプロジェクトフォルダのスキャンなし:53.48s

4


Macよりも10秒以上遅いですが、大幅に向上しています。

これは私が思う公式のドキュメントから通知されるべきです。

全てのコメント80件

+1

こんにちは@OshotOkill! ヤーンをお試しいただきありがとうございます。 CygwinまたはWSL( "Bash on Ubuntu on Windows")を使用していますか? どちらもディスクIOのパフォーマンスがかなり悪いことが知られています。

また、React Nativeには膨大な数のファイルがあるため、それらをnode_modulesコピーするのはかなり遅く、Windows上の多くの小さなファイルのディスクIOは一般にMac OSよりも遅くなります(Linux ext4よりも遅くなります)。 このシナリオでパフォーマンスを向上させるハードリンク(#499)を試すタスクがあります。

キャッシュなしで同じネットワーク環境

Yarnの主な改善点は、ウォームキャッシュがある場合(つまり、パッケージを少なくとも1回インストールした後)ですが、React Nativeを使用すると、膨大な数のファイルが速度低下の原因にもなります。

@ Daniel15いいえ、Cygwin / MinGW / MSYS2またはWSLを使用していません(後者は節のあるバグのために失敗します)。

あなたの説明によると、問題はファイルシステム(NTFS)が原因であると推測できますか? ウォームキャッシュが存在する場合でも、コピープロセスの実行速度はMacOSよりもはるかに遅くなります。

開発チームができるだけ早く解決策を考え出すことができることを願っています。 ありがとう。

私は同じを見ています。

インストール、node_modulesのワイプ、インストール

MacBookProは17秒かかり、私のWindowsマシンは122秒かかります。

これは、node_modulesとグローバルヤーンキャッシュを継続的にスキャンするアンチウイルスソフトウェアに関連している可能性があると誰かが指摘しました。 それらのフォルダに対して無効にしてみてください。

@cpojer私は彼らが正しいと思います。 プレインストールされたWindowsDefenderを除いて、マシンにウイルス対策ソフトウェアがないため、グローバルキャッシュフォルダーとプロジェクトフォルダーのスキャンを禁止し、いくつかのテストを行いました。

デフォルト:128.08s

2


キャッシュフォルダのスキャンなし:104.43s

3


プロジェクトフォルダのスキャンなし:78.28s

5


キャッシュフォルダとプロジェクトフォルダのスキャンなし:53.48s

4


Macよりも10秒以上遅いですが、大幅に向上しています。

これは私が思う公式のドキュメントから通知されるべきです。

これは、node_modulesとグローバルヤーンキャッシュを継続的にスキャンするアンチウイルスソフトウェアに関連している可能性があると誰かが指摘しました。

いいキャッチ! 私はすでに自分のコンピューターにc:\srcホワイトリストに登録しているので、これを完全に忘れていました。

@ OshotOkill -Windowsのインストール手順で、ウイルス対策アプリに関するメモをWebサイトに追加するプルリクエストを送信しますか? 編集する必要のあるファイルは次のとおりです: https

@OshotOkillほど細心の注意を払っていませんでしたが、ソースとノードインストールフォルダーに例外を追加し、yarn、npm、ノードバイナリを特に免除しました。これで、Windowsでの新規インストール時間は122秒から50秒に短縮されました。 。

@ Daniel15 PRは準備ができています。 私の英語が下手であることをお詫びします。

PRが統合されました。 この問題を閉じます。

これは、Windowsでは依然として痛々しいほど遅く、アンチウイルスとWindowsDefenderを非アクティブ化することさえあります。 これは(このアンチウイルスソリューションのような)単なる環境問題ではないと思いますが、無関係な依存関係をインストールしても、yarnがすべてのファイルを1つずつコピーしようとしているようです。

変更が必要なファイルを削除/コピーしないのはなぜですか? 私が持っていた場合はwebpackインストールをして、私はインストール時に変更されていませんrimraf 、それはローカルnode_modulesフォルダにキャッシュから再びコピーする必要はありません。

これについてもStackOverflowの記事を作成しました: http

ちなみに、私の(デュアルブート)Ubuntuベンチマークでは、Windowsが通常実行しているものと同じNTFSドライブを使用していました。 そこはまだ速いです。

Windows Defenderの除外にnode.exeを追加すると、パフォーマンスが大幅に向上しましたhttp://126kr.com/article/1884rsed7l

絶対にやってみます!

速度が少し向上したようです212-> 170秒
したがって、それは役立つように見えますが、Linuxよりも3倍以上遅いため、改善される可能性があります。

私が気付いたもう1つの問題-Windowsのインデックスサービスは、node_modules内のすべてのファイルにインデックスを付けようとします。
本当に必要ないので、 http://www.softwareok.com/?seite = faq-Windows-10 &faq

私のウィンドウは問題のパスにインデックスを付けるように設定されていないので、それでも問題は解決しません。

したがって、要約すると、パフォーマンスを向上させる4つの方法があります。

  • AVからプロジェクトフォルダをホワイトリストに登録
  • AVからYarnキャッシュディレクトリ((%LocalAppData%Yarn))をWhiteilst
  • Windows Defenderの除外にnode.exeを追加する
  • node_modulesフォルダー上のWindowsでインデックスサービスを無効にする

@Altianoはい、でもMac / Linuxに近いパフォーマンスを得るにはまだ十分ではありません

ヤーンをnpmと同じかそれより速くするには、AVまたはディレクトリのインデックス作成を無効にする必要があるというのはちょっと大雑把なようです。 結局のところ、npmではこれを行う必要はありません。 私はyarnを試してみることにしました。それは、高速であり、オフラインインストールによって、ネットワーク接続なしのコーディングがもっともらしいものになったからです。 リンクを最適化する方法はありませんか?

ここに関連するいくつかの問題と上記のコメントによると、他のいくつかの解決策を収集するために、この問題を再開したいと思います。

個人的には、テストマシンのハードウェア構成を一覧表示し、関連する写真をいくつかアップロードすることをお勧めします。 Yarn自体ではなく、プラットフォーム間で大きな違いをもたらす他の多くの無関係な要素が存在する可能性があります。つまり、MacBook上のSSDのベンチマークパフォーマンスは、通常、Windowsマシンよりもはるかに優れています。

@OshotOkillは、前に述べたように、同じ_ntfs_ドライブ上の同じ通常のPCで、関連するディレクトリのインデックスとWindowsDefenderを無効にしたWindowsとLinuxでパフォーマンスが3.5倍遅くなりました。 ntfsでも、Linuxでははるかに高速であると私は思います。

この理由を見てみましょう。
インストール中に移動される多数のファイルでNTFSの動作が遅くなる可能性がありますか?

誰かがこれを単一のマシンで再現する方法を共有できますか?
たとえば、Windowsラップトップにインストールされた特定のpackage.jsonはX秒かかりますが、VirtualBox Ubuntu Xで実行すると20%秒かかります。

@amcsi @bestanderよくあることですが、大量の小さなファイルをコピーする場合、EXT4 / XFSの方が高速です。 ただし、NTFSはそれほど遅くはありません。 キャッシュをクリーンアップし、最新バージョンのYarn and Node(0.19.1&7.5.0)を使用して再度テストしました。

a

react-nativeをインストールすると、結果はMacBookに非常に近くなります。 私がしたのは、関連するフォルダーとNode.exeプロセスをホワイトリストに登録することだけでした。

Windows Defenderでnode.exeプロセスとyarn.exeプロセスをプロジェクトディレクトリとともにホワイトリストに登録するまで、この問題が発生していました。 検索インデックスをまったく無効にしておらず、Yarnキャッシュディレクトリをホワイトリストに登録していません。 インストール時間は、中規模プロジェクトの190秒以上からクリーンキャッシュの約25秒になりました。 私のUbuntuマシンはそれより少し速いですが、5-10秒しかありません。

Fresh Yarn install

ハードウェア構成:
512GB SSD
12GBのRAM
AMD FX-83508コアCPU @ 4.01ghz
Windows 10 64ビット、ビルド14986。

自分のシステムで簡単なテストを行ったところです。 LinuxMintとWindows10を同じSSDからデュアルブートしました。 ヤーンキャッシュをクリーンアップし、 node_modulesを削除して、このvueプロジェクトでyarnました

Linux Mint:_12.22s_

yarnlinuxmint

Windows 10(ホワイトリストなし):_ 64.32s_

yarnwindows10

Windows 10(ホワイトリスト付き):_ 42.58s_

yarnwindows10_withexclusions

これらは、私がアクティブにしていたWindowsDefenderの除外です。
yarnwindows10_exclusions

ホワイトリストは重要な効果があるように見えましたが、それでもLinuxの速度に匹敵するほどではありませんでした。

編集: @bestanderの場合、これが私の正規化されたデータです:

| OS | 計算| 正規化されたデータ|
| --- | --- | --- |
| Linux Mint | 12.22 / 12.22 | 1 |
| Windows 10 | 64.32 / 12.22 | 5.2635 |
| Windows 10(ホワイトリスト付き)| 42.58 / 12.22 | 3.4845 |

@keawadeクリーンキャッシュからプロジェクトをインストールするのに26.48秒、キャッシュを使用してプロジェクトをインストールするのに13.58秒ありました。

keawade.github.io

ここで唾を吐くだけで、MSIインストーラーのYarn.cmdを使用していますが、NPMからインストールされたYarnを使用しているようです。 それらの間におそらく矛盾があるのだろうか?

@nozzlegearそれは可能かもしれませんが、インターネット接続の違いが原因である可能性よりも低いと思います。

これからネットワークを排除する必要があります。
現在、「LinuxonWindows」機能を有効にした最新のWindows10でこのリポジトリをテストできます。
プライムキャッシュを使用したCMDとBashの両方のインストールには、2コアi7プロセッサで約27〜29秒かかります。

@ keawade 、node_modulesを削除してキャッシュを配置した状態で、同じテストを実行できますか?

まだ使用しているデバイスに2つ目のOSをインストールできません。
仮想ボックスでWindowsとLinuxを実行すると異なる結果が得られるかどうかを誰かが確認できますか?

タイムスタンプhttps://github.com/yarnpkg/yarn/releases/download/v0.21.0-pre/yarn-0.21.0-0.jsで現在のマスターを構築しました

--verboseフラグを付けてインストールするために使用できますか?

例えば

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

すべてのFS操作にタイムスタンプを与える必要があります

キャッシュをクリーニングしないデータ

_注:このデータは、デュアルブートシステムで記録されています。 これらのテストでは、すべてのハードウェアが同一です。_

| OS | 平均時間| 正規化|
| ----------------------------- | ---------- | -------- ---- |
| Linux Mint | 5.598秒| 1.00000 |
| Windows 10(ホワイトリスト付き)| 12.119秒| 2.16488 |
| Windows 10(ホワイトリストなし)| 31.578s | 5.64094 |

_平均時間は、10回のテストのセット全体の平均です_

生のLinuxMintデータ

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

生のWindows10データ

ホワイトリスト付き

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

ホワイトリストなし

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

方法論

このPowerShellスクリプトを使用して、ここに示すすべてのデータを生成しました。 スクリプトはこのリポジトリのクローンを作成し、コマンドyarnを10回繰り返して実行し、各反復後にnode_modules削除します。

@bestander 、以前の投稿をWindowsデータで更新しました。

より多くのデータをありがとう。
両方のOSのタイムスタンプ付きのyarn.jsで--verboseバージョンを試すことができますか?
それは私たちに時間を費やす良い考えを与えるでしょう。

ふぅ、それはたくさんのロギングです! OSとホワイトリストの組み合わせごとに10回実行しますか、それとも1回で十分ですか。

@bestanderどうぞ! それぞれの1つ。

補足:最大30MBの生テキストを単一の要点コレクションにアップロードしようとすると、nginx405エラーが発生することが判明しました。 😆

〜Linux Mint〜
除外およびクリーンなWindows 10〜
除外あり、_clean_なしのWindows 10〜
クリーンで_exclusions_のないWindows 10〜
〜Windows 10_exclusions_および_without_cleanなし〜

VerboseLogs.tar.gz

編集:要点を削除し、圧縮ファイルをアップロードします。

最大30MBの生のテキストを単一の要点コレクションにアップロードしようとすると、nginx405エラーが発生することがわかりました。 😆

ファイル(bzip2または7-Zip)を圧縮して、ここに添付することができます...プレーンテキストは非常によく圧縮されます:)

@ Daniel15良い点です。圧縮ファイルは次のとおりです:

1回の実行で問題ありません:)

LinuxMint.txtとWindows10NoClean.txtを比較しました

Linux:

  • リンクフェーズは1.156秒から始まります
  • 1.968で作成されたnode_modules内のすべてのフォルダー
  • 3.873秒でコピーされた最後のファイル
  • ビルドはさらに3秒で完了します

ウィンドウズ

  • リンクフェーズは2.779秒で始まります
  • 4.83で作成されたnode_modules内のすべてのフォルダー
  • 32.853でコピーされた最後のファイル
  • ビルドはさらに3秒で完了します

明らかに、詳細なロギングはWindows(12-> 35秒)では実行時間に影響しますが、Linux(同じ6秒)では影響しません。

インターネットで見つけたベンチマークによると、Linux EXT3 FSは通常、大量のファイルがコピーされたときにNTFSよりもパフォーマンスが優れています。
これが私たちが直面しなければならない限界なのだろうか。

@ keawade 、WindowsとLinuxでnpm @ 3を使用すると速度が異なりますか?

いくつかのアイデア:

  • Windowsは同時コピーが苦手かもしれません。4つのスレッドでファイルをコピーします。 多分それはシングルスレッドですか?
  • たぶんWindowsでrobocopyラッパーを使用するhttps://github.com/mikeobrien/node-robocopy
  • readstream.pipe.writestreamを使用してファイルをコピーしますが、Windowsでは非効率的かもしれません

実験したい場合は、 https://github.com/yarnpkg/yarn/blob/master/src/util/fs.js#L32241に置き換えて、シングルスレッドコピーはWindowsで高速になります

スレッドテスト

@bestanderのリクエストyarnpkg/yarnをフォークし、 src/util/fs.js 322行目を変更して、 41に置き換えました。 次に、 yarn run buildを使用してプロジェクトをビルドし、ビルドによってコンパイルされたyarn.cmdを使用して、そのビルドで10個のテスト

| | 平均時間| 正規化|
| ---------------------------- | ---------- | --------- --- |
| Windows 10(ホワイトリスト付き)| 12.119秒| 1.00000 |
| シングルコピースレッド| 16.927s | 1.39673 |
| シングルコピースレッド+クリーン| 42.268s | 3.48775 |

_平均時間は、10回のテストのセット全体の平均です_

ファイルをコピーするために単一のスレッドのみを使用すると、インストール時間がわずかに遅くなるようです。

生データ

Windows 10(ホワイトリスト付き)

このデータは以前のテストからのものです

シングルコピースレッド

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

シングルコピースレッド+クリーン

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

ありがとう、@ keawade。
NTFSはLinuxFSよりも多数のファイルのコピーに時間がかかる可能性があるという私の仮定を確認できますか?

LinuxMintとWindows10の両方で、ターミナルが完全にインストールされたnode_modulesを介して別の場所にコピーすることを測定してください。

オプション/mt (マルチスレッドコピー)を指定したrobocopyを使用してコピーをテストすることも必要です。

また、報告された可能性のあるバグについても報告したいと思います。このバグでは、 yarn addまたはyarn removeごとに約30〜40分かかります。 どうやらすべての依存関係を再びコピーしているようですが、私はWindowsを使用しているため、これには長い時間がかかります。 リンクされた問題を参照してください:

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

@ kumarharsh #2458インストールが完了するまでに28

image

また、キャッシュだけでなく、プロジェクトフォルダもホワイトリストに登録することを忘れないでください。

コピーテスト

このスクリプトを使用してyarnを実行した後、このリポジトリをコピーしました。 これらは私の結果です。

| OS | 平均時間| 正規化|
| ------------ | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |

その時差はおかしいです。 これらのコピーは、_同じSSD_上のある場所から別の場所にファイルをコピーして行われました。

生データ

Linux Mint

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

ウィンドウズ10

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

現在、robocopyをテストする時間がありませんが、仕事の後に今晩そのデータを取得できます。

Robocopyテスト

このスクリプトを使用してyarnを実行した後、このリポジトリをコピーしました。 これらは私の結果です。

| OS | 平均時間| 正規化|
| ----------------------- | ------------ | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10(Robocopy)| 58089.7457 | 38.03024 |

Robocopyは、通常のコピーよりもわずかにパフォーマンスが低下しました。

生データ

LinuxMintとWindows10の値は、以前のテストからのものです

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

@keawade 、ファイルのインデックス作成とDefenderがコピーに干渉しないことを確認できますか?
Afaikは、cpコマンドでも関与する可能性があります。

コピーが完了したら、タスクマネージャーで何がアクティブになっているかを確認します。
そして多分ただテストのためにそれらのサービスをオフにします

インデックス作成とディフェンダーテスト

次の条件でテストを実行しました。

  • WindowsDefenderが無効になっている
  • Windowsインデックスサービスが無効になっている
  • _both_が無効になっているWindowsDefenderとWindowsIndexingサービス
  • WindowsDefenderとWindowsIndexingサービスの両方を無効にすると、Yarnキャッシュがクリーンアップされます

Windows Defenderを無効にするために、 Windows Defenderの設定パネルでReal-time protectionオフに切り替えました。

Windowsのインデックス作成を無効にするために、[サービス]コントロールパネルでWindowsSearchサービスを停止しました。

_注:Windows Defenderが有効になっている場合、除外は表示されませんでした_

このスクリプトを使用してyarnを実行した後、このリポジトリをコピーしました。 これらは私の結果です。

概要

Windowsインデックス(検索サービス)はコピー操作とYarnに影響を与えますが、より大きな影響はWindowsDefenderからもたらされるようです。

コピー

| OS | 平均時間| 正規化|
| -------------------------------------------- | ---- -------- | ------------ |
| Linux Mint | 1527.4620 | 1.00000 |
| Windows 10(ディフェンダーなし)| 7301.4307 | 4.78011 |
| Windows 10(インデックス作成なし)| 10307.0794 | 6.74787 |
| Windows 10(ディフェンダーなし、インデックスなし)| 7044.1393 | 4.61166 |
| Windows 10 Robo(ディフェンダーなし、インデックスなし)| 10094.8358 | 6.60889 |

インデックス作成インデックス作成とウイルス対策を完全に無効にすると、ファイルをコピーする際のパフォーマンスが大幅に向上します。

上記の結果は非常に顕著だったので、これらの条件下でもヤーンのパフォーマンスに関するデータを使用できると思いました。

このスクリプトを使用してyarnを10回繰り返し実行しました。このリポジトリのクローンを作成し、ディレクトリでyarnました。

| OS | 平均時間| 正規化|
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint | 5.5980 | 1.00000 |
| Windows 10(ディフェンダーなし)| 16.5450 | 2.95552 |
| Windows 10(インデックス作成なし)| 38.5170 | 6.88049 |
| Windows 10(ディフェンダーなし、インデックスなし)| 16.8490 | 3.00982 |
| Windows 10 Clean(ディフェンダーなし、インデックス作成なし)| 30.7730 | 5.49714 |

生データ

Linux Mintの値は、以前のテストからのものです。

Windows10コピーアイテム

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

Windows10Robocopy

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

Windows10ヤーン

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

Windows10ヤーンクリーン

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

Windows10のヤーンインデックスが無効

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

Windows10コピーインデックスの無効化

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

Windows 10 Yarn WindowsDefenderが無効になっています

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

Windows10コピーWindowsDefender無効

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

これは確かな調査です、 @ keawade 、すべてのデータを共有してくれてありがとう。
データは、生のファイルシステムのパフォーマンスがWindowsへのヤーンインストールのボトルネックであることを示唆しています。
制限を回避するスマートコピーコマンドがない限り、Yarnがここで何かを実行できるかどうかはわかりません

@keawadeこれらの数値をコンパイルするのに多大な@bestanderそれ以来ママ npmはコピー(永続スキャン)中にこれらの同じ問題に直面しません、多分糸は署名されていませんか? WindowsDefenderがnpmと同じレベルのyarnを信頼していない可能性があります。 ちょっとした考え...

@ kumarharsh 、npmとyarnの違いを測定する必要があります。
たぶんnpmはコピーするファイルが少なくなっています(Yarnの巻き上げは最小のnode_modulesツリー用に最適化されていません)。
そして、インストーラーを介して糸を自動的にホワイトリストに登録できれば素晴らしいと思います。

多分糸は署名されていませんか? WindowsDefenderがnpmと同じレベルのyarnを信頼していない可能性があります。

スクリプトに署名できるとは思わないので(Authenticode署名をサポートするPowerShellスクリプトを除く)、Yarnとnpmはその点で異なるとは思いません。 Yarnのインストーラーは、npmと同じようにAuthenticodeで署名されています。

そして、インストーラーを介して糸を自動的にホワイトリストに登録できれば素晴らしいと思います。

ウイルススキャンのホワイトリストに自動的に触れると、ウイルススキャナーがインストーラーをマルウェアとしてマークするようになります。 やるのは危険なことのようです。 ただし、検索インデクサーでディレクトリを自動的にブラックリストに登録することもできます。

@keawadeオプション/E /MT (マルチスレッドコピー)を使用してrobocopyをテストしました。

| コピー方法| 平均時間|
| ---------------------- | ---------- |
| コピーアイテム-Recurse | 20219 |
| Robocopy /E | 26652 |
| Robocopy /E /MT | 9043 |

生データ(Windows 10)

コピーアイテム-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]

スクリプトに署名できるとは思わないので(Authenticode署名をサポートするPowerShellスクリプトを除く)、Yarnとnpmはその点で異なるとは思いません。 Yarnのインストーラーは、npmと同じようにAuthenticodeで署名されています。

合理的に聞こえます。
これを再確認できますか?
npm install実行している場合、インデクサーとディフェンダーはタスクマネージャーに表示されますか?

NPMディフェンダーとインデックステスト

このリポジトリnpm installを実行するのにかかった時間を、YarnおよびWindowsのコピー方法のインデックス作成およびディフェンダーテストと同じ条件のセットで記録しました。

| OS | 平均時間| 正規化|
| --------------------------------------------- | --- ------- | ------------ |
| Linux Mint(糸)| 5.5980 | 1.00000 |
| Linux Mint(NPM)| 28.9793 | 5.17672 |
| Windows 10(ディフェンダーなし)| 42.6296 | 7.61514 |
| Windows 10(インデックス作成なし)| 53.8791 | 9.62470 |
| Windows 10(ディフェンダーなし、インデックスなし)| 37.9727 | 6.78326 |
| Windows 10(変更なし)| 58.5047 | 10.45100 |

概要

NPMはWindowsDefenderの影響も受けているようです。

生データ

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]

WindowsDefenderが無効になっているNPM

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

Windowsインデックスが無効になっているNPM

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

WindowsDefenderとWindowsインデックスが無効になっているNPM

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

一般的なIO操作の数を減らし、インデックス作成とディフェンダーについて人々を教育することにより、ディスクIOでWindowsが遅くなるという制限を回避する必要があると思います。
コピーをrobocopyに置き換えることも良い考えのようです。

一般的にIO操作の数を減らす

これは一般的には良い考えであり、どこでもパフォーマンスを向上させるのに役立ちます。 また、低速のハードドライブを搭載したサーバー上に構築する人々にとっても非常に有益です。

ここで、Windowsます

-更新
ただし、copyBulkには、単一のrobocopyコマンドに変換されない可能性のある除外などの追加のロジックがあるため、これは最適ではない可能性があります。

なぜこれが私のために(毎回)起こるのか誰かが知っていますか?

image

投稿を拡張するには:
私のWindowsマシンでは、すべてのyarn addまたはyarn rmプロジェクト内のすべてのノードモジュールを再コピーyarn add直前に行ったyarn rm paper操作のタイミングを観察します-1000秒!

そして、これらのadd/rm操作の1つをキャンセルすることはできません。これは、node_modulesフォルダーを台無しにし、後続のyarn install / npm installはすべての依存関係をインストールしないためです。つまり、最終的には最終的にrm -r node_modules/ 、最初からやり直します。 この単一の理由は、私がヤーンインストールをまったく使用するのを止めるのに十分なほど痛いです。

node_modulesがひどく持ち上げられていると思いますが、このバグは#2676で修正される予定です。

@bestanderによる#2620でのハードリンクの導入(管理者権限がなくてもWindows 7で正常に機能します)により、全体的なインストール時間とnode_modules/サイズが減少しました。

ハードリンクなし:

Done in 167.76s.

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

du -sh node_modules/
216M    node_modules/

ハードリンクあり:

Done in 58.07s.

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

du -sh node_modules/
189M    node_modules/

0.21.1を待ち、それが巻き上げに@kittens「修正を持っています。
さらに速くなるはずです

20時04分の水、2017年2月15日には、ハトソンベッツ[email protected]書きました:

@bestanderhttps ://github.com/bestanderの紹介で
#2620でのハードリンクhttps://github.com/yarnpkg/yarn/pull/2620
管理者権限がなくてもWindows7で正常に動作します)、私の全体
インストール時間とnode_modules / sizeが削除されました。

ハードリンクなし:

167.76秒で完了。

実際の2分49秒633
ユーザー0m0.229s
sys 0m1.368s

du -sh node_modules /
216M node_modules /

ハードリンクあり:

58.07秒で完了。

実数0分59.967秒
ユーザー0m0.183s
sys 0m1.369s

du -sh node_modules /
189M node_modules /


あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/yarnpkg/yarn/issues/990#issuecomment-280122923 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ACBdWAEghXfPo4bX9mN0hV8l8YaH2rmlks5rc1pigaJpZM4KVwpA

私はWin7 / w Yarnv0.21.3を使用しています

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

yarn add ...新しいパッケージを追加するには、この時間待つ必要がありました
ディフェンダーオフ
インデックス作成が無効

@Altianoが前述したように、これらの手順に従うだけで、他のAVを実行することができます。

AVからプロジェクトフォルダをホワイトリストに登録
AVからYarnキャッシュディレクトリ((%LocalAppData%Yarn))をWhiteilst

これで更新されます

@kuncevic 、プロジェクトのクリーンインストール時間は
ファイル内のnode_modulesフォルダーのサイズはどれくらいですか?
npm installと比較してどうですか?

@bestanderこれは私と同じ問題です。 yarn addまたはyarn removeは、 @ kittensの巻き上げを修正した後でも、同じ時間がかかります。

これが発生するたびに:

  1. まず、 Fetching packagesが実行されます(約30秒かかります)。
    image
  2. 次に、依存関係のリンクが約1〜2分間一時停止します。
    image
  3. その後、次のステップから再開し、63kファイルを再度インストール(?)します。
    image

私が言ったように、これは私がyarn addまたはyarn removeを実行するたびに起こります。 インストールする依存関係が他の依存関係に依存しているかどうかは関係ありません。新しい依存関係をインストールしたり、既存の依存関係をアップグレードしたりするための単純なnpm installは、この時間のほんの一部です。 @kittensの巻き上げ修正により、

@bestander再現可能なケースが必要な場合は、次のリポジトリのクローンを作成してください: httpsyarn installを実行してから、 yarn add react-helmetます。

Yarnは、add / removeを実行するたびに決定論を保持しているため、依存関係が変更されたときに、依存関係がnode_modulesのルートに引き上げられたかどうかを確認する必要があります。
そのため、完全なリンクフェーズが実行されます。

依存関係の取得-ダウンロードしてください。最適化することはできません。
最初のリンクフェーズ(1561操作)-すべての依存関係のすべてのフォルダーを作成します。
2番目のリンクフェーズ(63K操作)-ファイルをキャッシュからnode_moduesにコピーします。

Yarnは、コピーを実行する前にファイルが同じであるかどうかを確認することにより、ファイルのコピー操作を最適化します。
この領域のプロファイルを改善して、不要なIOの数を減らすことができるかどうかを確認することをお勧めします。
たぶん、Windowsではコピーはチェックよりも速いでしょうか?

npmはどうですか、クリーンインストールはどれくらいの速さですか?

npm( npm install )のクリーンインストールには552301.1944msです。
追加の依存関係( npm install weird )をインストールするには、 57023.7593msです。 (この時間のほとんどは、キャンバスをdepとしてインストールしようとするpaperjsで無駄になりますが、この時間はnpmとyarnの両方に共通です)

ヤーン( yarn install )のクリーンインストールには612698.4915msです。
追加の依存関係( yarn add weird )をインストールするには、 495633.0307msです。

npm version 3.10.9
yarn version 0.21.3

@bestander @kumarharsh Yarnは、ノード7.1以降に存在しないlibuv / nodejsバグ(Yarnコードの潜在的な修正については#2958を参照)が原因で、Windowsでのファイルコピー操作を最適化しないため、2番目のコマンドを取得できます( yarn add )ノードをアップグレードするだけではるかに高速になります。

Windowsのファイルコピー操作を使用すると、ノードAPIを使用してファイルをコピーするよりも少し速く(潜在的なPRについては#2960を参照)、 yarn installを少し最適化できますが、それがで正当化されるかどうかはわかりませんnpm(テストしませんでした)

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.

しかし、実行してyarn add rimrafその中で行われました20.52s.が、なぜyarn install削除した後にnode_modulesそう長く取って?

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ノードのアップグレードがyarn add機能することを確認できてうれしいです:)

空のnode_modulesに関しては、糸が原因である量と、ファイルシステム、ハードドライブ、およびアンチウイルスが原因である量を測定することをお勧めします。
私がテストしたのは、 material2の完全なnode_module (npmではなくyarnによって生成されたもの)をyarnキャッシュのどこかにコピーすることでした。

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

次に、テストごとにnode_modulesをクリーンアップし、以前に作成したフォルダーからyarn installnpm installまたはxcopyを実行しました。

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

そして、合計秒かかりました。

結果

これが3台のPCでの結果です

  • 🏠家庭用PC:Samsung 950 Pro NVMe、ESET Nod32
  • 🏢仕事用PC:Samsung 850 EVO SATA、無効にできないTrendMicroウイルスバスターCorp.
  • 🍎MacBookPro:2015バージョン、macos、アンチウイルスなし

|| yarn 🏠| npm 🏠| xcopy 🏠| yarn 🏢| npm 🏢| xcopy 🏢| yarn 🍎| npm 🍎
|-|-|-|-|-|-|-|-|-
| AV無効| 34秒| 90年代| 23年代| 92秒
| AVキャッシュとコードを除外| 38秒| 104秒| 29秒|-|-|-|-|-
| Avキャッシュのみを除外| 43s |-| 31s |-|-|-|-|-
| AVフル| 48秒| 122秒| 32秒| 100年代| 274秒| 236秒|-|-

AVが有効になるたびに、 yarn installまたはxcopy間にCPUチャートをトッピングしていました(自宅のPCでは合計30%のCPUが最大で取得されましたが、職場のPCではxcopyの1つのコアがいっぱいになります&すべての私の毛糸のコア)
xcopyは私の仕事用PCではyarnよりも遅いです。yarnのようにファイルを並列にコピーしないためだと思います(これはIOバウンド操作では問題ではありませんが、AVはCPUバウンド操作になり、xcopyは書き込まれませんでしたそんなに愚かと戦う😄)

結論として

  • yarnnpmよりも高速であり、AVがファイルコピーをCPUにバインドすると、 xcopyよりも高速になる可能性があります。
  • 優れたSSD上のWindowsは、まったく同じパッケージがインストールされているわけではなく、すべてのインストール後のスクリプトが同じことを行うわけではないため、比較が難しい場合でも、MacBook Pro 2015(すでに優れたSSDを搭載)遅くはありません。
  • それを回避するためにいくつかの変更をヤーンで行うことができますが(ファイルのシンボリックリンク?)、本質的に多くの小さなファイルの対処は遅いです
  • Windows AVでは、
  • 企業のAVは、自宅のAV遅くなり、コピー操作が苦痛になるほどパフォーマンスが低下する可能性があります(自然にIOバウンド操作がCPUバウンドになる場合)😡

npm、yarnキャッシュフォルダー、node.exeを防御側の除外リストに追加するだけで十分です。もちろん、これらすべてをインデックス付きフォルダーに含めることはできません。 今、糸の追加/ rmは7秒かかります

皆さんに感謝します。Windowsの大幅な最適化が0.24に到達しましたhttps://github.com/yarnpkg/yarn/pull/3234#issuecomment-297552326

@vbfoxベンチマークnpmyarnバージョン番号を追加していただけますか?

これはまだMacOSXのたわごとです

私はまだいくつかのクレイジーなインストール時間を経験しています。 yarn addは、すべて( package.json内のすべてのアイテム、最大30kの依存関係)を常にインストールしてリンクしているようです。

Linuxバージョン:

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

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

2つ(半)の質問があります:

  1. このスレッドの問題に対して受け入れられている解決策は何ですか? それは#3234でしたか、それともWindows Defenderを微調整しましたか?

    • 解決策がWindowsDefenderを微調整していた場合、どこかで何をすべきかについての完全な記述はありますか?
  2. 私の問題は実際にこのスレッドに関連していますか、それとも新しいスレッドを作成する必要がありますか?

新しい問題を提起してくれてありがとう、私はそこで返答します

もう1時間近く経ちましたが、このコマンドがプロセスを完了するのを待っています。 @Altianoが述べた上記のポイントに

これに代わるものはありますか? npm i -g .を使用できますか?同じように動作しますか、このコードはworkspace使用しているため、いくつか変更を加える必要があります

したがって、最終的に2〜3時間苦労した後、 npm i -g .代わりにyarn global add file:. npm i -g .を使用する必要がありました。 npmは魅力のように機能しました

このページは役に立ちましたか?
0 / 5 - 0 評価