Yarn: 需要针对Windows的重大优化

+1

嗨@OshotOkill！ 感谢您尝试使用Yarn。 您是否正在使用Cygwin或WSL（“ Windows上的Ubuntu上的Bash”）？ 众所周知，两者的磁盘IO性能都非常差。

另外，React Native具有大量文件，因此将它们复制到node_modules相当慢，并且Windows上许多小文件的磁盘IO通常比Mac OS慢（Mac OS本身比Linux ext4慢）。 我们确实有一个任务要尝试使用硬链接（＃499），这可以改善这种情况下的性能。

没有缓存和相同的网络环境

使用Yarn的主要改进是在拥有良好的缓存时（即，至少安装了一次软件包之后），但是使用React Native时，大量文件也将导致某些速度变慢。

@ Daniel15不，我没有使用Cygwin / MinGW / MSYS2或WSL（由于一个棘手的错误，后者失败了）。

根据您的描述，我可以假设问题是由文件系统（NTFS）引起的吗？ 即使存在热缓存，复制过程仍然比MacOS运行慢得多。

希望开发团队能尽快提出解决方案。 谢谢。

我也一样

做安装，擦拭node_modules，安装

MacBookPro需要17秒，我的Windows计算机需要122秒。

有人指出这可能与防病毒软件不断扫描node_modules和全局纱线缓存有关。 您可以尝试为那些文件夹禁用它吗？

@cpojer我想他们是对的。 除预装的Windows Defender之外，我的计算机上没有任何防病毒软件，因此我禁止扫描全局缓存文件夹和项目文件夹，并进行了一些测试：

默认值：128.08秒

不扫描缓存文件夹：104.43s

不扫描项目文件夹：78.28s

不扫描缓存文件夹和项目文件夹：53.48s

尽管它比Mac慢了10多个秒，但它具有显着的提升。

这应该从我认为的官方文档中得知。

有人指出这可能与防病毒软件不断扫描node_modules和全局纱线缓存有关。

接得好！ 我完全忘记了这一点，因为我已经在计算机上将c:\src列入了白名单。

@OshotOkill-您要提交拉请求，在Windows安装说明中向网站添加有关防病毒应用程序的注释吗？ 这是您需要编辑的文件： https :

我不像@OshotOkill那样细致，但是我为源代码和节点安装文件夹添加了例外，然后专门免除了yarn，npm和node二进制文件，现在我在Windows上的全新安装时间从122秒减少到50秒。

@ Daniel15 PR准备就绪。 抱歉我的英语不好。

公关已合并。 关闭此问题。

在Windows上，这仍然非常缓慢，甚至会停用反病毒和Windows Defender。 我不认为这只是环境问题（就像这种防病毒解决方案一样），但是即使安装了一些不相关的依赖项，似乎似乎yarn也会尝试以1比1的方式复制所有文件。

为什么不删除/复制需要更改的文件呢？ 如果我安装了webpack并且在安装rimraf时未进行修改，则不必再次将其从缓存复制到本地node_modules文件夹中。

我也创建了关于此的StackOverflow文章： http :

顺便说一下，在我的（双引导）Ubuntu基准测试中，我使用的NTFS驱动器与Windows通常运行的驱动器相同。 而且那里还是很快。

将node.exe到Windows Defender排除项使我获得了巨大的性能提升http://126kr.com/article/1884rsed7l

我一定会尝试的！

它似乎确实提高了速度212-> 170秒
因此它似乎有所帮助，但仍可以改进，因为它的速度仍然比Linux慢3倍以上

我注意到的另一个问题-Windows上的索引服务尝试索引node_modules中的每个文件。
我真的根本不需要它，因此我禁用了它http://www.softwareok.com/?seite=faq-Windows-10&faq=53并获得了另一个性能提升。

我的窗口未设置为所讨论路径的索引，因此仍然无法解决问题。

综上所述，有四种提高性能的方法：

• 从AV将白名单项目文件夹
• 从AV白化Yarn缓存目录（（％LocalAppData％Yarn））
• 将node.exe到Windows Defender排除项
• 在Windows的node_modules文件夹上禁用索引服务

@Altiano是的，但是仍然不足以使性能接近Mac / Linux

似乎有些粗略，您必须禁用AV或目录上的索引才能使yarn比npm更快或更快。 毕竟，您不必在npm上执行此操作。 我决定试一试，因为它表示速度很快，并且脱机安装使无需网络连接即可进行编码成为可能。 有没有办法优化链接？

根据与此处相关的一些问题以及上面的评论，我想重新讨论此问题，以便收集其他解决方案。

我个人建议列出有关测试计算机的硬件配置，并上传一些相关图片。 平台之间可能会有许多其他不相关的因素，而不是Yarn本身有很大的不同，即MacBook上SSD的基准性能通常比Windows机器好得多。

就像我之前说的，@ OshotOkill在与_ntfs_驱动器相同的普通PC上，在Windows和Linux上性能下降了3.5倍，而Linux和Linux禁用了相关目录的索引和Windows Defender。 我认为，即使在ntfs上，在Linux上也要快得多。

让我们找出原因。
在安装过程中移动大量文件时，NTFS的工作速度可能会变慢吗？

任何人都可以在单台计算机上共享一种复制方式吗？
例如，安装在Windows笔记本电脑上的特定package.json需要X秒，但在VirtualBox Ubuntu中运行需要20％秒。

@amcsi @bestander通常，EXT4 / XFS在复制大量小文件时速度更快。 但是，NTFS并没有慢很多。 我刚刚清理了缓存，并使用最新版本的Yarn和Node（0.19.1＆7.5.0）再次进行了测试：

结果是在安装react-native时实际上接近MacBook。 我所做的只是将相关文件夹和Node.exe进程列入白名单。

我一直遇到这个问题，直到我将Windows Defender中的node.exe和yarn.exe进程以及我的项目目录列入白名单。 我根本没有禁用搜索索引，也没有将Yarn缓存目录列入白名单。 安装时间从一个中型项目的190多秒减少到一个干净的缓存大约25秒。 我的Ubuntu机器比这快一点，但是仅5-10秒。

硬件配置：
512GB SSD
12GB RAM
AMD FX-8350 8核CPU @ 4.01GHz
Windows 10 64位，内部版本14986。

我只是在自己的系统上进行了一些快速测试。 我已经从相同的SSD上启动了Linux Mint和Windows 10双重启动。 我清理了纱线缓存，删除了node_modules并在该vue项目上运行了yarn 。

Linux Mint：_12.22s_

Windows 10（无白名单）：_64.32s_

Windows 10（带有白名单）：_42.58s_

这些是我曾经使用过的Windows Defender排除项目：

尽管白名单似乎确实起到了很大的作用，但它仍然无法与Linux上的速度相提并论。

编辑：对于@bestander ，这是我的规范化数据：

| 操作系统| 计算归一化数据
| --- | --- | --- ||
| 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.48s从干净的缓存中安装项目，还有13.58s从缓存中安装项目。

只是在这里吐口水，我正在使用MSI安装程序中的Yarn.cmd，看起来您正在使用从NPM安装的Yarn。 我想知道它们之间是否可能存在差异？

@nozzlegear虽然这可能是可行的，但我认为它的可能性要小于互联网连接的差异。

我们需要从中消除网络。
目前，我可以在启用了“ Windows上的Linux”功能的最新Windows 10上测试此存储库。
在2核i7处理器上，通过CMD和带有主要缓存的Bash安装都需要花费大约27-29秒的时间。

@keawade ，您可以在删除node_modules却保留缓存的情况下运行相同的测试吗？

我无法在已安装的设备上安装第二个操作系统。
谁能检查在“虚拟”框中运行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操作提供时间戳记

无需清理缓存的数据

_注意：此数据正在双引导系统上记录。 这些测试的所有硬件都相同。

| 操作系统| 平均时间| 归一化
| ----------------------------- || ---------- | -------- ---- |
| Linux Mint 5.598秒| 1.00000 |
| Windows 10（带白名单）| 12.119秒| 2.16488 |
| Windows 10（无白名单）| 31.578秒| 5.64094 |

_平均时间是一组10次测试的平均值_

原始Linux Mint数据

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

Windows 10原始数据

有白名单

[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数据更新了上

太好了，谢谢您提供更多数据。
您是否可以在两个操作系统上都使用带有yarn.js的带有时间戳的--verbose版本？
这会给我们一个好主意，花时间在哪里。

哇，这是很多日志记录！ 您是否要为每个操作系统/白名单组合进行10次运行，还是每次运行都足够好？

@bestander你去！ 一人一个。

旁注：事实证明，如果您尝试将〜30mb的原始文本上传到单个gist集合，则会出现nginx 405错误。 😆

〜Linux Mint〜
〜Windows 10带有排除项并且干净〜
〜Windows 10带有排除项，不带_clean_〜
〜Windows 10干净且没有_exclusions_〜
〜不带_exclusions_和_without_ clean的Windows 10〜

VerboseLogs.tar.gz

编辑：删除要点并上传压缩文件。

事实证明，如果您尝试将〜30mb的原始文本上传到单个gist集合，则会收到nginx 405错误。 😆

您可以压缩文件（bzip2或7-Zip）并将其附加在此处...纯文本压缩得很好:)

@ Daniel15好点，这里是压缩文件： VerboseLogs.tar.gz

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#L322中将4替换1在Windows上单线程复制变得更快

线程测试

根据@bestander的请求，我分叉了yarnpkg/yarn并修改了src/util/fs.js 322行，将4替换为1 。 然后，我使用yarn run build来构建项目，并使用由该版本编译的yarn.cmd对该版本进行10个测试。 这些就是结果。

| | 平均时间| 归一化
| ---------------------------- | ---------- | --------- --- |
| Windows 10（带白名单）| 12.119秒| 1.00000 |
| 单拷贝线程| 16.927秒| 1.39673 |
| 单拷贝线程+清洁| 42.268秒| 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复制大量文件的速度可能比Linux FS慢？

请测量通过终端完整安装的node_modules复制到Linux Mint和Windows 10中的另一个位置。

还需要使用robocopy和/mt选项测试副本（多线程副本）

我还想报告一个可能报告的错误，其中每个yarn add或yarn remove大约需要30-40分钟。 显然，它再次复制了所有依赖关系，并且由于我在Windows上，因此需要很长时间。 看到链接的问题：

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

@kumarharsh ＃2458我花了28

另外我必须提到，不要忘记将项目文件夹也列入白名单，而不仅仅是缓存。

复制测试

我使用此脚本在Linux Mint和Windows 10上运行了10个副本副本。在目录中运行yarn之后，我复制了此仓库。 这些是我的结果。

| 操作系统| 平均时间| 归一化
| ------------ | ------------ | ------------ |
| Linux Mint 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |

那个时差太疯狂了。 这些副本是通过将文件从同一位置的文件从一个位置复制到另一位置而完成的。

原始数据

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

我现在没有时间测试自动复制，但是今天晚上下班后我可以得到这些数据。

复印机测试

我使用此脚本在Linux Mint和Windows 10上运行了10个副本副本。在目录中运行yarn之后，我复制了此仓库。 这些是我的结果。

| 操作系统| 平均时间| 归一化
| ----------------------- | ------------ | ------------ |
| Linux Mint 1527.4620 | 1.00000 |
| Windows 10 | 53676.3155 | 35.14085 |
| Windows 10（自动复制）| 58089.7457 | 38.03024 |

Robocopy的效果比普通副本差一些。

原始数据

Linux Mint和Windows 10值来自之前的测试

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

@keawade ，您可以验证文件索引
Afaik它甚至可以参与cp命令。

完成复制后，检查任务管理器中的活动内容。
也许只是关闭这些服务进行测试

索引和防御者测试

我在以下条件下进行了测试：

• 禁用Windows Defender
• 禁用Windows索引服务
• 禁用_both_的Windows Defender和Windows索引服务
• 禁用_both_的Windows Defender和Windows索引服务_and_清理Yarn缓存

要禁用Windows Defender，我在Windows Defender设置面板下关闭了Real-time protection 。

要禁用Windows索引编制，我在“服务”控制面板中停止了Windows Search服务。

_注意：启用Windows Defender时，未列出任何排除项_

我使用此脚本在Linux Mint和Windows 10上运行了10个副本副本。在目录中运行yarn之后，我复制了此仓库。 这些是我的结果。

概要

Windows索引（搜索服务）确实会对复制操作和Yarn产生影响，但更大的影响来自Windows Defender。

复制中

| 操作系统| 平均时间| 归一化
| -------------------------------------------- | ---- -------- | ------------ |
| 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 |

索引完全禁用索引和防病毒功能可极大地提高复制文件时的性能。

纱

由于上述结果非常明显，因此我认为我们也可以在这些条件下使用有关纱线性能的数据。

我使用此脚本在Linux Mint和Windows 10上运行yarn 10次​​迭代。我克隆了此存储库，并在目录中运行了yarn 。

| 操作系统| 平均时间| 归一化
| --------------------------------------------- | --- ------- | ------------ ||
| 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值来自先前的测试。

Windows 10复制项目

[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纱线

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

Windows 10纱线清洁

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

Windows 10纱线索引已禁用

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

Windows 10复制索引已禁用

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

Windows 10纱线Windows Defender禁用

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

Windows 10复制Windows Defender已禁用

[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在复制（永久扫描）时不会遇到这些相同的问题，也许纱线未签名？ 可能是Windows Defender不信任npm级别的纱线。 只是一个想法...

@kumarharsh ，然后我们需要测量npm和yarn之间的差异。
也许npm正在复制较少的文件（未针对最小的node_modules树优化纱线的提升）。
如果我们能够通过安装程序自动将纱线列入白名单，那就太好了。

也许纱线没有签名？ 可能是Windows Defender不信任npm级别的纱线。

我不认为脚本可以签名（PowerShell脚本确实支持Authenticode签名），因此我认为Yarn和npm在这方面不会有所不同。 纱线的安装程序是Authenticode签名的，就像npm一样。

如果我们能够通过安装程序自动将纱线列入白名单，那就太好了。

我觉得自动触摸病毒扫描白名单会导致病毒扫描程序将安装程序标记为恶意软件。 这样做似乎很冒险。 不过，也许我们可以在搜索索引器中自动将目录列入黑名单。

@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]

我不认为脚本可以签名（PowerShell脚本确实支持Authenticode签名），因此我认为Yarn和npm在这方面不会有所不同。 纱线的安装程序是Authenticode签名的，就像npm一样。

听起来很合理。
我们可以仔细检查一下吗？
如果运行npm install ，Indexer和Defender是否出现在任务管理器中？

NPM防御者和索引测试

我记录了在与用于纱线和Windows复制方法的索引和防御程序测试相同的一组条件下，在此仓库上运行npm install时间。

| 操作系统| 平均时间| 归一化
| --------------------------------------------- | --- ------- | ------------ ||
| 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也受Windows Defender的影响。

原始数据

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]

禁用Windows Defender的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]

NPM与Windows Defender和Windows索引已禁用

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

我想我们需要通过减少总体上IO操作的数量并教育人们有关Indexing和Defender的方法来解决Windows在磁盘IO上速度较慢的限制。
用robocopy替换副本似乎也是一个好主意。

通常减少IO操作的数量

总的来说，这是一个好主意，将有助于在各处进行演练。 对于在硬盘驱动器速度慢的服务器上构建的人们来说，这也可能非常有益。

期待有一个PR，可以在此处使用robocopy替换fs流管道。

-更新
但是，这可能不是最佳选择，因为copyBulk具有一些额外的逻辑，例如可能无法转换为单个robocopy命令的排除逻辑。

有谁知道为什么这会在我身上每次发生？

要扩展帖子：
在我的Windows机器上-每一个yarn add或yarn rm重新复制项目中的所有节点模块，这使得package.json的每一次更改都需要花费很长时间才能完成。 每次都有16万个依赖项的进度条出现，它像被困在油田中的乌龟一样爬行。 观察我在yarn add之前执行的yarn rm paper操作的时间-1000秒！

而且取消这些add/rm操作之一是不可能的，因为它弄乱了node_modules文件夹，任何后续的yarn install / npm install都不会安装所有依赖项-这最终意味着我最终做了rm -r node_modules/然后重新开始。 这个单一的原因非常痛苦，使我完全无法使用纱线安装。

我认为您的node_modules悬挂异常，该错误将在＃2676中修复

随着@bestander的引入＃2620（在Windows 7中没有管理员权限的正常工作）hardlinking的，我的整体安装时间，和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到提升的修复。
应该更快

在2017年2月15日星期三20：04，Hutson Betts [email protected]写道：

随着@bestander https://github.com/bestander的介绍
＃2620中的硬链接https://github.com/yarnpkg/yarn/pull/2620 （其中
在没有管理员权限的Windows 7中可以正常工作），总体而言
安装时间和node_modules /大小已删除。

没有硬链接：

完成于167.76秒钟。

真正的2m49.633s
用户0m0.229s
sys 0m1.368s

du -sh node_modules /
216M node_modules /

使用硬链接：

完成于58.07秒钟。

真正的0m59.967s
用户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 Yarn v0.21.3

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

必须等待这段时间，用yarn add ...添加任何新软件包
后卫
索引已禁用

还有其他一些AV正在运行，因此只需按照@Altiano上面提到的这些步骤进行操作

从AV将白名单项目文件夹
从AV白化Yarn缓存目录（（％LocalAppData％Yarn））

将对此进行更新

@kuncevic ，该项目的干净安装时间是多少？
文件中的node_modules文件夹的大小是多少？
与npm install相比有什么不同？

@bestander这是我的同样问题。 任何yarn add或yarn remove花费相同的时间-大约，即使在@kittens吊装修复之后。

每次发生这种情况：

1. 首先， Fetching packages运行（大约需要30秒）：
   
2. 然后，链接依赖项暂停大约1或2分钟。
   
3. 然后，继续进行下一步，并再次安装（？）63k文件。
   

就像我说的那样，这每次我运行yarn add或yarn remove 。 我要安装的依赖项是否依赖于任何其他依赖关系都没有关系，一个简单的npm install用于安装新的依赖项或升级现有的依赖项只需要一小部分时间。 @kittens的提升修复确实使性能提高了2

@bestander如果您想要可重现的案例，请克隆此https : yarn install ，然后运行yarn add react-helmet 。

每次运行添加/删除时，Yarn都会保留确定性，因此当依赖项更改时，它需要检查是否有任何依赖项被提升到node_modules的根目录。
这就是为什么它运行完整链接阶段。

获取依赖项-下载，您无法对其进行优化。
第一个链接阶段（1561操作）-它为所有依赖项创建所有文件夹。
第二个链接阶段（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由于节点7.1+上没有出现libuv / nodejs错误（有关纱线代码的潜在修复方法，请参见＃2958），Yarn无法优化Windows上的文件复制操作，因此您可以获取第二条命令（ 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 ，要做的一件好事是测量多少是由于毛线引起的，多少是由于FileSystem，硬盘驱动器和防病毒引起的。
我所做的测试，这是复制的全node_module （如纱产生的，而不是NPM）的material2纱线缓存的地方：

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 install ， npm install或xcopy ：

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

并花费了总秒数。

结果

这是3台PC上的结果

• 🏠家用电脑：三星950 Pro NVMe，ESET Nod32
• 🏢工作电脑：无法禁用的三星850 EVO SATA，趋势科技OfficeScan
• 🍎MacBook Pro：2015版，macOS上，无防病毒

|| yarn 🏠| npm 🏠| xcopy 🏠| yarn 🏢| npm 🏢| xcopy 🏢| yarn 🍎| npm 🍎
|-|-|-|-|-|-|-|-|-
| AV已禁用| 34s | 90s | 23s |-|-|-| 32s | 92秒
| AV排除缓存和代码| 38s | 104s | 29s |-||-|-|-|-
| Av仅排除缓存| 43s |-| 31s |-|-|-|-|-
| 满额| 48s | 122s | 32s | 100s | 274秒| 236秒|-|-

每次启用AV时，它都会在yarn install或xcopy期间切换CPU图表（在我的家用PC上，最大使用了30％的cpu，但在我的工作PC上，它填充了一个用于xcopy的内核和我所有的纱芯）
我怀疑xcopy在我的工作PC上比yarn慢，我怀疑是因为它不会在yarn时并行复制文件（对于IO绑定操作不重要，但是AV使它成为CPU绑定操作，而xcopy未写入打这么愚蠢😄）

结论

• yarn比npm更快，甚至在绑定AV make文件复制CPU时甚至可以比xcopy更快。
• 即使很难比较，因为安装了不完全相同的软件包，并且很难比较，采用优质SSD的Windows并没有比MacBook Pro 2015（已经具有优质SSD）的
• 可以在纱线上进行一些更改以避开这种变化（符号链接文件？），但是从本质上来说，处理许多小文件很慢
• 在Windows AV上可以使其变慢，在源文件夹和目标文件夹中同时启用时，我的添加量为30％😞
• 公司AV可能比家用AV

将npm，纱线缓存文件夹和node.exe添加到防御者的排除列表中就足够了，当然，所有这些都不能放在索引文件夹中。 现在添加纱线/均方根需要7秒

谢谢大家，Windows的重大优化降落在0.24 https://github.com/yarnpkg/yarn/pull/3234#issuecomment -297552326

@vbfox能否在基准中添加npm和yarn版本号？

对于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

我有两个（半个）问题：

1. 什么是该线程中可接受的解决方案？ 是＃3234还是要调整Windows Defender？

   • 如果解决方案是对Windows Defender进行调整，那么是否有完整的说明在某处做什么？

2. 我的问题实际上与此线程有关，还是应该创建一个新线程？

感谢提出新问题，我会在那儿回复

现在已经快一个小时了，我正在等待此命令完成该过程。 我已经遵循@Altiano提到的上述要点，但没有任何效果

我们对此有其他选择吗？ 就像我可以使用npm i -g .一样吗，或者我必须做一些更改，因为此代码使用yarn workspace

因此，最终在奋斗2-3小时之后，我不得不使用npm i -g .而不是yarn global add file:. 。 npm就像魅力一样