为什么 ruby​​ 在 Windows 上慢这么多？

Why is ruby so much slower on windows?

提问by srboisvert

What are the specific technical causes of Ruby being so much slower on Windows? People report about a 3X speed drop from Linux/OSX and there are some vague discussions about Ruby using a compiler for Windows versions that produces slow code but I can't find any specific details.

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

Anybody know the specifics? I'm not interested in hurf durf Windoze sucks yuk yuks.

有人知道具体情况吗？我对 hurf durf Windoze 很烂 yuk yuks 不感兴趣。

采纳答案by PierreBdR

I would guess there are a few possible options, and they probably all add up:

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

1. Ruby being mainly developed on Linux, it ends up mechanically optimised for it. The code is regularly tested for Windows and everything works, but the result is still that developer will spend more time optimising for Linux than Windows.
2. To my experience, recent versions of gcc (4.3 and greater) produce code more efficient than recent versions of Visual Studio (at least 2005). My tests included in both case spending about a day finding the best options for code optimisation.
3. Related to point 1, if you compile the same project using gcc for Windows or Linux, I usually observe a drop of performances of about 20% on Windows compared to Linux. Here again, I suppose this is because Linux (or Unices in general) is a primary target for gcc, windows is a port. Less time is spent optimising for Windows than Linux.

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

In the end, if one would want to optimise Ruby for Windows, a significant amount of time (and money, as far as I know, profilers on Windows don't come for free) will have to be spent using a profiler and optimising bottlenecks. And everything will have to be tested on Linux to make sure there is no loss of performance.

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

Of course, all than should be tested again with their new interpreter YARV.

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

回答by anelson

I've not done much work with the source code of the YARV interpreter, so the following comments pertain only to the 1.8.6 MIR interpreter.

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

In the course of trying to write a C extension for Ruby in Visual Studio, I discovered to my horror that the downloadable Windows binaries of Ruby 1.8.6 are compiled using Visual C++ 6.0, which was released shortly after the end of the Second World War. Since then compilers (and the processors they target) have advanced considerably. While the Linux builds get the latest gcc goodness, the Windows build limps along with last century's compiler technology. That's one reason. (Disclaimer: supposedly 1.9 is to be built with mingw, of which I am not a fan, but which also must be better than VC6)

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

Without knowing what ops in particular you find slower on Windows it's hard to comment further, but I will note that I found the I/O implementation on Ruby to be considerably less performant with both network and local file I/O. I never delved into the implementation of the I/O primitives enough to see why, but I assume the implementations assume the fast IO constructs on Linux are the fast IO constructs on Windows, which is almost always not the case.

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

回答by Thorsten

Not completely to your question, but there was a great discussion on the Deep Fried Bytes podcastthat discussed the same question in the IronPython context. I understand your question pertains to Ruby, but there may be related issues that also affect Ruby.

不完全是针对您的问题，但是在Deep Fried Bytes 播客上有一个很好的讨论，该播客在 IronPython 上下文中讨论了相同的问题。我了解您的问题与 Ruby 有关，但可能存在也会影响 Ruby 的相关问题。

Also, the discussion does a good job of looking a bit deeper than "Windows sucks", so it's worthwhile to check it out.

此外，该讨论做得很好，比“Windows 糟糕透了”更深入一点，因此值得一看。

回答by kgiannakakis

At first you need to make a distinction between the older MRI interpreter(versions up to 1.8) and the newer YARV, which is the official interpreter for Ruby 1.9. There are big performance improvements and a different design in Ruby 1.9, so one needs to know which version you are talking about. I am guessing that what you've read refers to 1.8.x version, which is the only one that has an one-click installer so far.

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

Also, it would be good to know if you are talking about Ruby on Rails performance or Ruby in general. I know that there should be a clear distinction between these two, but because Ruby on Rails is the main use of Ruby, people often talk about its performance as if they were speaking about Ruby's performance.

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

As for the compiler, Ruby can be built using any recent version of Visual Studio, which is more than fine. I guess that if such a performance difference does exist, one should look at the implementation of the interpreter and see if there is something that would make a difference between a POSIX and a Windows system.

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

回答by wvdschel

The performance bump is not 300%, in general, instead, it is closer to 50%-100%. Casual Jim's explanation is one of the reasons why data processing scripts are slower on Windows compared to Unix-variants and Linux.

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

In the more general case, the only thing I can think of is that Ruby development is Linux-centered, which has lead to many Unix-isms in the way Ruby was built. Also, since most active developers are not Windows users, very little Windows optimization expertise is present in the team, and most performance optimizing decisions are focused on making things faster on Unix systems.

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

A specific example of this is that Ruby uses copy-on-write parameter passing, which, according to what I read, can't be done properly on Windows, causing a lot of overhead in method calls.

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

I can't seem to figure out though, what Casual Jim did to deserve the -8 vote.

我似乎无法弄清楚，休闲吉姆做了什么值得-8票。

回答by jj_

ntfs automatic file compression on windows was slowing up everything for me. it starts working automatically when you are low on hd space... and then it needs to decompress and recompress files on the fly, as you access them, wasting cpu cycles..

Windows 上的 ntfs 自动文件压缩对我来说减慢了一切。当您的高清空间不足时，它会自动开始工作……然后它需要在您访问文件时动态解压缩和重新压缩文件，浪费 CPU 周期。

Run the following command to uncompress a whole ntfs drive from its root (i.e. "C:\") and see if there are any differences, to me it made a huge difference and got ruby/rails speed back to what i was used to before !

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

command is:

命令是：

compact /u /s /i