与原生 Windows NPM/Yarn 处理相比，为啥 WSL 非常慢？

Posted 2023-02-19

【中文标题】与原生 Windows NPM/Yarn 处理相比，为啥 WSL 非常慢？

【英文标题】：Why is WSL extremely slow when compared with native Windows NPM/Yarn processing?与原生 Windows NPM/Yarn 处理相比，为什么 WSL 非常慢？

【发布时间】：2021-10-28 12:24:53

【问题描述】：

我最近经常使用 WSL，因为我需要一些本机 UNIX 工具（而且模拟器还不够好）。我注意到使用 NPM/Yarn 时的速度差异令人难以置信。

我进行了一个简单的测试，证实了我的感受。测试正在运行 npx create-react-app my-test-app，WSL 结果为 Done in 287.56s.，而 GitBash 以 Done in 10.46s. 结束。

这不是全部情况，因为在这两种情况下感知时间都更长，但即使基于此 - 某处也存在大问题。我只是不知道在哪里。我正在进行的项目使用了数十个库，即使更改其中一个也需要几分钟而不是几秒钟。

这是我可以解决的问题吗？如果是这样 - 去哪里寻找线索？

附加信息：

我的处理器：处理器 AMD Ryzen 7 5800H，带 Radeon Graphics，3201 Mhz，8 核，16 个逻辑处理器

我正在运行 Windows 11，其中包含系统和 WSL 的所有最新更新。选择的系统是 Ubuntu 20.04

我见过一些类似'npm install' extremely slow on Windows 的问题，但它们根本不涉及 WSL（而且我的纯 Windows NPM 运行速度很快）。

问题不仅限于 NPM，也适用于 Yarn

我遇到的另一个问题是文件监视没有发生（我需要在每次更改时重新启动服务器）。在某些应用程序中我没有收到任何错误，有时我会收到以下信息：

Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'

npm start 在一个空的（新初始化的）create-react-app 中需要很长时间才能在 WSL 中的浏览器中呈现某些内容，并且在从 GitBash 执行时 - 我可以在 2-4 秒内看到内容

这可能是纯粹的 WSL 问题，但在使用 NPM/Yarn 时伤害最大

【参考方案1】：

由于您提到在 Git Bash 中执行相同的文件（具有适当的性能），我将在这里做一个假设。如果我错了，请纠正我，我会删除答案并寻找另一种可能性。

如果您的文件存储在 /mnt/c（又名 C:，或 Git Bash 下的 /C）或任何其他 Windows 驱动器上，这将被解释（和预期），因为它们可能需要被访问通过 Git Bash。

WSL2 使用 9P 协议访问 Windows 驱动器，目前已知它非常慢于：

本机 NTFS（显然） WSL2 使用的虚拟磁盘上的 ext4 文件系统 甚至 WSL1 与 Windows 驱动器的性能

我看到一个大型 repo（WSL2 Linux 内核 Github）的 git clone 在 Windows 驱动器上的 WSL2 上需要 8 分钟，但在根文件系统上只需要几秒钟。

两种可能：

如果可能（并且适用于大多数 Node 项目），请使用 wsl --set-version <distroname> 1 将您的 WSL 转换为版本 1。我始终建议先使用wsl --export 进行备份。

既然您无论如何都要进行备份，那么您也可以通过wsl --import将您的备份设置为--version 1（作为最后一个参数）来创建实例的副本。 WSL1 和 WSL2 都有自己的用途，您可能会发现同时保留它们会有所帮助。

有关确切语法的更多详细信息，请参阅this answer。

或者只是将项目移到 WSL 根目录下的某个位置，例如 /home/username/src/。

【讨论】：

嘿，首先 - 非常感谢您的全面回答。是的 - 我所有的文件都存储在/mnt/c 下。我尝试了您的第二个解决方案 - 它在终端中的运行速度与预期一样快，但是当我第一次加载 create-react-app 项目 [IntelliJ Ultimate] 时，IDE 冻结了。有趣的是，第二次运行成功了——我将用我的实际项目进行更多测试。谈到切换到 WSL1 - 我隐约记得我需要升级，因为 WSL1 缺少 WSL2 的一些功能（我正在使用 Solana 开发的 BPF 编译器运行 Rust），所以我不能这样做

我将把我的真实项目转移到/home/username/...，看看 IDE 如何处理整个事情。如果它有效 - 我很乐意接受你的回答，现在我会 +1 （因为我相信它可能会在未来帮助某人 - 请不要删除它）免责声明：是的，我使用 Rust 作为我这个项目的主要编程语言，但 node 用于 E2E 测试，因此它两者兼有 - 因此我使用 npm 作为一个更广为人知的例子来描述这个问题。还有 - 一些 npm 库（用于测试 solana）只能在 *nix 系统下工作

IDE 速度要慢得多，并且在打开更多实例时会冻结（以前从未发生过），但我想它已经足够快了，我现在只使用该解决方案。谢谢:) PS。您是否有任何关于此问题是否会在未来得到解决的信息？有没有为它打开的 github 问题？

@WrRaThY 这是用于跟踪的主要issue，虽然我已经阅读了 Microsoft 团队的声明，他们对性能不满意，但我不知道提到的根本原因（但我还没有通读关于这个问题的所有 350 多个 cmets）除了可能缺乏 9P 中的缓存支持。

@WrRaThY 另外，我之前没有注意到您问题的“观看”部分，但是是的，这也是由于 9P。有关更多信息，请参阅this question/answer。请注意，如果您从 VSCode 中运行应用程序，观看似乎可以工作。

【参考方案2】：

以@notthedr01ds 的回应为基础。

如果您查看 Microsoft 的 Comparing WSL 1 and WSL 2，整个操作系统的性能在 WSL2 中明显更差。

我的案子落到Exceptions for using WSL 1 rather than WSL 2

您的项目文件必须存储在 Windows 文件系统中。 WSL 1 提供对从 Windows 挂载的文件的更快访问。 如果您将使用 WSL Linux 发行版访问 Windows 文件系统上的项目文件，而这些文件无法存储在 Linux 文件系统上，则使用 WSL 1 将在整个 OS 文件系统中实现更快的性能。

这意味着我需要切换到版本 1。

wsl --set-version Ubuntu 1
Conversion in progress, this may take a few minutes...
Conversion complete.

之前测试

>time git status
...
real    0m6.436s
user    0m0.055s
sys     0m36.380s

之后测试

> time git status
...
real    0m0.126s
user    0m0.016s
sys     0m0.641s