在Windows上，Ruby的特定技术原因是什么？人们报告Linux / OSX的速度下降了3倍，并且有一些模糊的讨论关于Ruby使用Windows版本的编译器产生的代码很慢，但我找不到任何具体的细节。
有人知道具体细节吗？我对hurf durf不感兴趣，Windoze糟透了yuk yuks。
答案 0 :(得分：21)
我猜有几个可能的选择，他们可能都加起来了：
最后，如果有人想要针对Windows优化Ruby，那么大量的时间（以及资金，据我所知，Windows上的分析器不是免费提供的）将不得不花费在使用分析器上并优化瓶颈。所有内容都必须在Linux上进行测试，以确保不会损失性能。
当然，应该再次使用他们的新翻译进行测试 YARV
答案 1 :(得分：15)
我没有对YARV解释器的源代码做过多少工作，因此以下注释仅适用于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构造，几乎总是不是这样。
答案 2 :(得分：2)
首先，您需要区分较旧的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系统产生影响。
答案 3 :(得分：2)
不完全是你的问题，但是对于在IronPython上下文中讨论相同问题的Deep Fried Bytes podcast进行了很好的讨论。我理解您的问题与Ruby有关，但可能存在影响Ruby的相关问题。
此外，讨论的效果比“Windows糟透了”要好得多，所以值得一试。
答案 4 :(得分：1)
性能提升不是300％，一般来说，它接近50％-100％。休闲吉姆的解释是Windows上数据处理脚本比Unix变种和Linux慢的原因之一。
在更一般的情况下，我唯一能想到的是Ruby开发是以Linux为中心的，这导致了Ruby构建方式中的许多Unix主义。此外，由于大多数活跃的开发人员不是Windows用户，因此团队中存在非常少的Windows优化专业知识，并且大多数性能优化决策都侧重于在Unix系统上加快速度。
一个具体的例子是Ruby使用copy-on-write参数传递，根据我读到的，在Windows上无法正常完成，导致方法调用中的大量开销。
我似乎无法弄清楚，休闲吉姆做了什么值得-8投票。
答案 5 :(得分：-1)
Windows上的ntfs自动文件压缩对我来说减慢了一切。 当你在高清空间不足时它会自动开始工作...然后它需要动态解压缩和重新压缩文件，因为你访问它们，浪费cpu周期..
运行以下命令从其根目录解压缩整个ntfs驱动器（即“C：\”）并查看是否存在任何差异，对我来说它产生了巨大的差异并将ruby / rails速度恢复到我的状态以前习惯了！
命令是：
compact /u /s /i