为什么 ruby 在 Windows 上这么慢？答案

【问题标题】：Why is ruby so much slower on windows?为什么 ruby 在 Windows 上这么慢？
【发布时间】：2010-10-29 13:03:53
【问题描述】：

Ruby 在 Windows 上如此缓慢的具体技术原因是什么？人们报告说 Linux/OSX 速度下降了 3 倍，并且有一些关于 Ruby 使用 Windows 版本的编译器产生缓慢代码的模糊讨论，但我找不到任何具体细节。

有人知道具体情况吗？我对 hurf durf Windoze 糟透了不感兴趣。

【问题讨论】：

我认为 Ruby 代码已被解释。 ?
是的，但解释器仍然需要编译。最常见的实现是用 C 编写的。
当前的稳定版本 (1.9.1) 使用了一个名为 YARV 的新 VM，它是一个 JIT 引擎。
其实我不相信 YARV 使用任何 JIT 编译。
你能用例子证明 Ruby 在 Windows 平台上慢了 3 倍吗？它是在各个方面都变慢还是仅在某些任务上变慢？请记住，您应该在两种情况下（Linux/Windows）都使用等效的机器进行比较。

标签： windows ruby

【解决方案1】：

我猜有几个可能的选项，它们可能都加起来：

Ruby 主要在 Linux 上开发，最终针对它进行了机械优化。代码定期针对 Windows 进行测试，一切正常，但结果仍然是开发人员将花费更多时间针对 Linux 进行优化而不是 Windows。
根据我的经验，最新版本的 gcc（4.3 和更高版本）生成的代码比最新版本的 Visual Studio（至少 2005 年）更高效。在这两种情况下，我的测试都花费了大约一天的时间来寻找代码优化的最佳选项。
与第 1 点相关，如果您使用 gcc for Windows 或 Linux 编译相同的项目，我通常观察到与 Linux 相比，Windows 上的性能下降约 20%。再说一次，我想这是因为 Linux（或一般的 Unices）是 gcc 的主要目标，Windows 是一个端口。与 Linux 相比，用于 Windows 优化的时间更少。

最后，如果想要为 Windows 优化 Ruby，则必须花费大量时间（和金钱，据我所知，Windows 上的分析器并不是免费提供的）使用分析器并优化瓶颈。一切都必须在 Linux 上进行测试，以确保没有性能损失。

当然，所有这些都应该用他们的新解释器再次测试 YARV.

【讨论】：

AMD CodeAnalyst 和 Intel 的 Vtune 均免费提供 :-)
广告 3. 为 Windows 或 Linux 优化代码没有区别，只有硬件平台更改才能有所作为。
VS8/9 构建的 MRI 比 MinGW 构建的 MRI 慢。上次我查了一下，官方的 Windows 二进制文件是用 VS6 构建的，速度更慢；不过，那是不久前的事了。我切换到 JRuby for Windows 并没有回头。
作为参考，我参加了 RubyConf 2013，我什至不记得见过一台不是 Mac 的计算机。我听说有一个 linux 笔记本电脑的传闻，但它可能是在 macbook 上运行的 linux。

【解决方案2】：

我没有对 YARV 解释器的源代码做太多工作，因此以下 cmets 仅适用于 1.8.6 MIR 解释器。

在尝试在 Visual Studio 中为 Ruby 编写 C 扩展的过程中，我惊恐地发现 Ruby 1.8.6 的可下载 Windows 二进制文件是使用 Visual C++ 6.0 编译的，该版本在第二次世界大战。从那时起，编译器（以及它们所针对的处理器）有了长足的进步。虽然 Linux 构建获得了最新的 gcc 优点，但 Windows 构建与上个世纪的编译器技术一起跛行。这是原因之一。（免责声明：据说1.9是用mingw构建的，我不是它的粉丝，但它也必须比VC6更好）

如果不知道在 Windows 上哪些操作特别慢，很难进一步评论，但我会注意到，我发现 Ruby 上的 I/O 实现在网络和本地文件 I/O 上的性能要差得多。我从未深入研究 I/O 原语的实现以了解原因，但我认为这些实现假设 Linux 上的快速 IO 结构是 Windows 上的快速 IO 结构，但几乎总是如此。

【讨论】：

【解决方案3】：

不完全符合您的问题，但在 Deep Fried Bytes podcast 上进行了精彩的讨论，在 IronPython 上下文中讨论了相同的问题。我了解您的问题与 Ruby 有关，但可能存在也会影响 Ruby 的相关问题。

此外，这个讨论做得很好，看起来比“Windows 糟透了”更深入一些，所以值得一试。

【讨论】：

【解决方案4】：

首先，您需要区分较旧的MRI interpreter（最高版本为 1.8）和较新的 YARV，后者是 Ruby 1.9 的官方解释器。 Ruby 1.9 有很大的性能改进和不同的设计，所以需要知道你在谈论哪个版本。我猜你看到的是1.8.x版本，是目前唯一一个有一键安装的版本。

此外，如果您谈论的是 Ruby on Rails 性能还是一般意义上的 Ruby，这将是一件好事。我知道这两者之间应该有明显的区别，但是因为 Ruby on Rails 是 Ruby 的主要用途，所以人们经常谈论它的性能，就好像他们在谈论 Ruby 的性能一样。

至于编译器，Ruby 可以使用任何最新版本的 Visual Studio 构建，这非常好。我想如果确实存在这样的性能差异，那么应该查看解释器的实现，看看是否有什么东西会在 POSIX 和 Windows 系统之间产生差异。

【讨论】：

Ruby 1.9（带有 YARV）在 Windows 上仍然慢得多。（请注意，我实际上并没有做过任何基准测试，这只是我的不科学观察。）

【解决方案5】：

性能提升不是300%，一般来说，是接近50%-100%。随意 Jim 的解释是与 Unix 变体和 Linux 相比，Windows 上的数据处理脚本速度较慢的原因之一。

在更一般的情况下，我唯一能想到的是 Ruby 开发是以 Linux 为中心的，这导致了 Ruby 构建方式中的许多 Unix 主义。此外，由于大多数活跃的开发人员都不是 Windows 用户，因此团队中几乎没有 Windows 优化专业知识，大多数性能优化决策都集中在 Unix 系统上使事情变得更快。

这方面的一个具体例子是 Ruby 使用写时复制参数传递，根据我的阅读，这在 Windows 上无法正确完成，导致方法调用的开销很大。

不过，我似乎无法弄清楚，随便的 Jim 做了什么才配得上 -8 票。

【讨论】：

【解决方案6】：

Windows 上的 ntfs 自动文件压缩让我的一切都变慢了。当您的高清空间不足时，它会自动开始工作......然后它需要在您访问它们时即时解压缩和重新压缩文件，浪费 cpu 周期..

运行以下命令从根目录（即“C:\”）解压缩整个 ntfs 驱动器，看看是否有任何差异，对我来说，它产生了巨大的差异，并使 ruby/rails 速度恢复到原来的水平以前用过！

命令是：

compact /u /s /i

【讨论】：

这……安全吗？可能的副作用是什么？我问是因为我已经花费/浪费了很多时间来尝试为 ruby 构建/远程/使用 WSL/etc，以至于我最终认为这不值得，只是处理 Windows 上的缓慢问题。但如果我能加快速度，那将是理想的。（WSL 有其自身的复杂性，我只想使用一个环境并完成它。）
为什么不安全？我认为你应该只确保你有所需的可用空间。另一方面，我认为 Windows 不会让您完成这些文件的过程，这些文件在未压缩时会超过可用的可用空间。所以最坏的情况是一些压缩文件无法解压缩。此外，我很确定可能会有特定工具旨在更详细地管理本机 Windows 压缩，允许您管理要解压缩的文件和不解压缩的文件。
因为它弄乱了我整个驱动器的磁盘级设置？而且这似乎不是 ruby-on-windows 缓慢的根本原因？
@MaxCascone 你读过我的全部评论了吗？因为我充分阐述了你对安全问题提出的问题。然而，在您的后续评论中，您只是提出了修辞和争论性的问题，嵌入了您自己的答案。那么，如果你已经得到了很好的答案，你为什么还要问呢？我只是想帮忙。此外，我从未说过我的解决方案会修复the root cause of ruby-on-windows slowness。我只是说它对我有用。学点礼仪啊老哥！这不是你可能习惯的典型论坛，而且这种态度在这里也不能很好地容忍！
恢复七年前的线程是我的错。我承认我当时有点匆忙，没有微调我的方法就提出了后续问题。如果您客观地看待，我想您会意识到您以几次人身攻击作为回应，并指责我粗鲁和好争辩，而我会说您在没有任何挑衅的情况下在此线程中升级了语气。我同意 SO 是一个学习的地方，我一直努力做到尽可能尊重和乐于助人；也许我错过了这一点，我建议你也反思一下自己的反应。