为什么有人说 Ruby 很慢？ [关闭]答案

【问题标题】：Why do people say that Ruby is slow? [closed]为什么有人说 Ruby 很慢？ [关闭]
【发布时间】：2011-02-01 13:24:13
【问题描述】：

我喜欢 Ruby on Rails，并将它用于我所有的 Web 开发项目。几年前，有很多人谈论 Rails 是一个内存猪，以及它如何不能很好地扩展，但 Gregg Pollack here 搁置了这些建议。

不过，最近我听到有人说 Ruby 本身很慢。

为什么认为 Ruby 很慢？

我不觉得 Ruby 很慢，但我只是用它来制作简单的 CRUD 应用程序和公司博客。在我发现 Ruby 变慢之前，我需要做什么类型的项目？还是这种缓慢只是影响所有编程语言的原因？

作为 Ruby 程序员，如果您想处理这种“缓慢”，您有哪些选择？
哪个版本的 Ruby 最适合 Stack Overflow 等速度至关重要且流量密集的应用程序？

这些问题是主观的，我意识到架构设置（EC2 与独立服务器等）有很大的不同，但我想听听人们对 Ruby 速度慢的看法。

最后，我找不到太多关于 Ruby 2.0 的新闻——我认为我们距离那个版本还有好几年？

【问题讨论】：

What makes Ruby slow?的可能重复
youtube.com/… Ruby2.1
除了很好的答案外，没有一个人能真正回答为什么。 Nakilon 提到的相关问题中有更好的见解

标签： ruby performance

【解决方案1】：

为什么认为 Ruby 很慢？

因为如果您在 Ruby 和其他语言之间运行典型的基准测试，Ruby 就会失败。

我不觉得 Ruby 很慢，但后来再说一次，我只是用它来制作简单的 CRUD 应用程序和公司博客。我需要什么样的项目在我发现 Ruby 变成慢？还是这种缓慢只是影响所有编程的东西语言？

在编写实时数字信号处理应用程序或任何类型的实时控制系统时，Ruby 可能无法为您提供很好的服务。 Ruby（带有今天的 VM）可能会在智能手机等资源受限的计算机上窒息。

请记住，您的 Web 应用程序上的许多处理实际上是由用 C 开发的软件完成的。 Apache、Thin、Nginx、SQLite、MySQL、PostgreSQL、许多解析库、RMagick、TCP/IP 等都是 Ruby 使用的 C 程序。 Ruby 提供了粘合剂和业务逻辑。

作为 Ruby，您有哪些选择程序员，如果你想处理这“慢”？

切换到更快的语言。但这需要付出代价。这可能是值得的成本。但是对于大多数 Web 应用程序来说，语言选择并不是一个相关因素，因为没有足够的流量证明使用更快的语言是合理的，而开发成本更高。

哪个版本的 Ruby 最适合 Stack Overflow 之类的应用程序速度很关键，交通很重要的地方激烈？

其他人已经回答了这个问题 - JRuby、IronRuby、REE 将使您的应用程序的 Ruby 部分在能够负担 VM 的平台上运行得更快。而且由于导致缓慢的通常不是 Ruby，而是您的计算机系统架构和应用程序架构，您可以执行诸如数据库复制、多个应用程序服务器、使用反向代理的负载平衡、HTTP 缓存、memcache、Ajax、客户端缓存等.这些东西都不是Ruby。

最后，我找不到太多关于 Ruby 2.0 - 我认为我们是少数几年后呢？

大多数人都在等待 Ruby 1.9.1。我自己正在等待 JRuby 上的 Ruby 1.9.1 上的 Rails 3.1。

最后，请记住，许多开发人员选择 Ruby 是因为与其他语言相比，它使编程成为一种更愉快的体验，并且因为 Ruby 与 Rails 使熟练的 Web 开发人员能够非常快速地开发应用程序。

【讨论】：

经过深思熟虑，我认为这是最好的答案。谢谢，我喜欢关于信号处理应用程序的类比。在所有这些有用的答案之后，现在更容易看到人们在谈论什么。
是的，你距离 ruby 2 还差几年，Ruby 2.0.0 Released on 24th Feb 2013
我使用 Ruby 2.1 的经验是，它比在 Ruby 2.0 中运行的相同应用快约 25%
语言不慢不快，它们的实现、解释器和编译器是:)
@ZelphirKaltstahl 我来晚了，但我想对您的评论发表评论 :) 我同意解释器和编译器在程序的执行方式中发挥着重要作用，但语言也非常重要.像 Ruby 和 Python 这样的动态语言比静态类型语言慢，仅仅是因为它们需要在运行时进行大量类型检查。猴子补丁很酷，但很昂贵。

【解决方案2】：

首先，慢于什么？ C？ Python？让我们在Computer Language Benchmarks Game获取一些数字：

Ruby 1.9 vs. Python3 在相同数量级内
Ruby 1.9 vs. PHP 在相同数量级内
Ruby 1.9 vs. Java 6 server 最多慢两个数量级！
Ruby 1.9 vs. C (gcc) 最多慢两个数量级！
...

为什么认为 Ruby 很慢？

取决于你问谁。你可能会被告知：

Ruby 是一种解释型语言，解释型语言往往比编译型语言慢
Ruby 使用垃圾收集（尽管 C# 也使用垃圾收集，但在算法更强大、内存分配密集程度更低方面比 Ruby、Python、PHP 等领先两个数量级以上基准）
Ruby 方法调用很慢（尽管由于鸭子类型，它们可以说比强类型解释语言更快）
Ruby（JRuby 除外）does not support true multithreading
等

但是，再一次，慢于什么？ Ruby 1.9 与 Python 和 PHP 一样快（在 3 倍的性能因素内），而 C 语言（可以快 300 倍），所以上面的（除了线程考虑之外，如果你的应用程序严重依赖这方面) 主要是学术性的。

如果您想处理这种“缓慢”，作为 Ruby 程序员，您有哪些选择？

为可扩展性而编写并投入更多硬件（例如内存）

哪个版本的 Ruby 最适合 Stack Overflow 等速度至关重要且流量密集的应用程序？

嗯，REE（结合Passenger）将是一个非常好的候选人。

【讨论】：

垃圾收集本身并不一定很慢，但 MRI 的垃圾收集却很慢。如果你需要更快的 Ruby，你也可以看看 JRuby 和 REE。
@igouy，确实，2008 年年中可能是极端情况。我更新了链接，但它们会在几个月后过时。 :) 无论哪种方式，硬件和一些补丁级别可能有所不同，并且添加了一些额外的测试，但事情的大局并没有改变。
>>在同一个数量级内
@igouy，我不了解你，但我不是一个用执行速度来衡量我的寿命的程序。例如，我关心执行速度的地方是 HTTP 响应呈现时间。我知道我不会注意到 7ms 和 69ms 渲染时间之间的差异（尤其是在 130ms 网络延迟之上时）。我知道我会注意到 7ms 和 700ms 之间的差异，我肯定会注意到 7ms 和 7s 之间的差异——但不，不是 7ms 和 69ms 之间的差异。
@vladr，70 毫秒或 700 毫秒呢？你能注意到这个区别吗？

【解决方案3】：

Rails 的创建者David Heinemeier Hansson 是这样说的：

Rails [Ruby] 适用于绝大多数人 Web 应用程序足够快。我们让网站做数以百万计的动态每天的页面浏览量。如果你最终在雅虎或亚马逊前线页面，不太可能 ANY 中的现成框架语言会给你带来很多好处。你会可能必须自己动手。但当然，我也想要空闲的 CPU 周期。一世只是碰巧更在乎免费的开发者周期，我愿意用前者换后者。

即在问题上投入更多的硬件或机器比雇用更多的开发人员和使用更快但更难维护的语言更便宜。毕竟，很少有人用 C 编写 Web 应用程序。

Ruby 1.9 是对 1.8 的巨大改进。 Ruby 1.8 最大的问题是它的解释性（没有字节码，没有编译），而且方法调用是 Ruby 中最常见的操作之一，速度特别慢。

在 Ruby 中几乎所有东西都是一个方法查找，这并没有帮助 - 添加两个数字，索引一个数组。其他语言暴露黑客的地方（Python 的__add__ 方法，Perl 的重载.pm）Ruby 在所有情况下都执行纯 OO，如果编译器/解释器不够聪明，这可能会损害性能。

如果我用 Ruby 编写一个流行的 Web 应用程序，我的重点是缓存。无论您使用什么语言，缓存页面都会将该页面的处理时间减少到零。对于 Web 应用程序，数据库开销和其他 I/O 开始比语言的速度更重要，所以我会专注于优化它。

【讨论】：

“毕竟，很少有人用 C 编写 Web 应用程序。” - 当然不是，但是许多性能关键的网站移动了，例如到斯卡拉。
我不同意“投入更多硬件”更便宜。很难说服客户他们应该每 X 个月支付更多的托管费用，因为他们的平台是为开发人员设计的。
@Keven：开发成本肯定会降低吗？否则，首先使用 Ruby 有什么意义？
@Kevin 这句话有点宽泛。如果您需要为每天大约 100 次访问的流量增加 10% 左右设置一个新服务器，那么客户显然有权投诉。但实际上，在旧硬件无法再应付之前，您通常需要有更多的流量开始并将其增加一个数量级。到那时，话题就进入了“一个很好的问题”领域，几乎没有人会抱怨升级硬件。此外，没有任何“客户”在不知道这些事情的情况下运行如此高流量的网站。
@Kevin - 让我们扭转局面。 “很难说服客户他们应该等待 3 个月才能获得新功能，因为他们的平台是在设计时考虑到计算机的。”如果该新功能会大幅增加收入，它将支付额外的硬件费用。此外，对于许多应用程序来说，从一开始就选择一种快速的语言是一种过早的优化。您的瓶颈很可能在其他地方：数据库读取、网络延迟等。

【解决方案4】：

编写代码很慢。阅读代码很慢。查找和修复错误很慢。添加功能和增强功能很慢。任何比以前有所改进的东西都是胜利。执行性能很少会成为问题。

【讨论】：

@GregS：如果执行性能影响可用性，它总是是个问题。诚然，从纯数字的角度来看，在一秒或三秒内扫描 xml 文件中的字符串并不重要，但是当您谈论面向用户的应用程序时，几秒钟的差异可能会对可用性产生很大影响。
@Bryan：同意，但我坚持我的“很少”资格。
执行性能始终是一个问题，我们所谈论的问题有多大。在用户停止购买您的应用程序之前，您可以在手机上运行多少解释代码，因为它会耗尽电池？用户在关闭广告之前等待您的页面加载多长时间会剥夺您的广告收入？回答这些问题，您就知道执行性能有多重要。
@dev Ajax 所做的调整是对算法的改进。它通过改变渐近线节省了大量的资源。算法改进通常是值得的。

【解决方案5】：

答案很简单：人们说 ruby 很慢，因为根据与其他语言的测量比较，它很慢。但请记住，“慢”是相对的。通常，ruby 和其他“慢”语言已经足够快了。

【讨论】：

是的，我就是这么想的，我的意思是，人们说它很慢，但对于我的要求来说仍然很快......
>> 对于我的要求，它仍然很快
我对此有部分偏见，也许考克斯这是一个过时的评论。现在我们有了 ruby 2.3，从 ruby 2.2 的经验来看，我发现 rails stack 很重。如果需要更快的框架，请尝试 pidrano，它基于 sinatra，他们尝试尽可能接近 rails 命令，但要轻得多。但他们还没有达到 1.0 版本，还有更多，但从我的测试来看，它运行得很好而且很快。我已经使用从轨道借来的活动记录 5 和 pidrano 链轮。有 200 个并发连接，我在没有 db 查询的情况下得到 1.5 秒的响应，资产来自 sprockets

【解决方案6】：

Joel on Software - Ruby Performance Revisited 很好地解释了它。不过可能已经过时了...

我建议您坚持使用它，因为您已经习惯了 Ruby on Rails，
如果您遇到性能问题，您可能会重新考虑使用不同的语言和框架。

在这种情况下，我真的会建议 C# 使用 ASP.NET MVC 2，它非常适合 CRUD 应用程序。

【讨论】：

感谢您的链接，我一直喜欢阅读 Joel 对事物的看法。他对 DHH 的“保险杠贴纸标语”发表了有趣的评论……
Quote: "这并不适用于所有人，但是当人们说他们对 Ruby 有性能问题或者他们只需要能够比核心 Ruby 语言引擎更快地运行代码时可以运行它，但让 Ruby 倡导者唱出关于开发人员周期与 CPU 周期的赞美诗也无济于事。”说得好。

【解决方案7】：

我会说 Ruby 很慢，因为没有花费太多精力来提高解释器的速度。这同样适用于 Python。 Smalltalk 与 Ruby 或 Python 一样动态，但性能要好很多，请参阅http://benchmarksgame.alioth.debian.org。由于 Smalltalk 或多或少被 Java 和 C# 取代（至少是 10 年前），因此没有对其进行更多的性能优化工作，而且 Smalltalk 仍然比 Ruby 和 Python 快得多。 Xerox Parc 和 OTI/IBM 的人有钱支付那些致力于使 Smalltalk 更快的人。我不明白为什么 Google 不花钱让 Python 变得更快，因为他们是一家大型 Python 商店。相反，他们花钱开发诸如 Go 之类的语言......

【讨论】：

我认为这是因为 Python 已经占有一席之地并且现在被大量使用。如果您需要高性能，您可以使用或编织许多库以及其他您可以使用的东西。
从我读到的一些努力已经在 Ruby 2.5 中产生了很好的结果。

【解决方案8】：

在许多容易测量的任务（例如，编写严重依赖浮点的代码）上，Ruby 比 C++ 慢。这并不奇怪，但足以让一些人毫无条件地说“Ruby 很慢”。他们没有考虑到编写 Ruby 代码比 C++ 更容易和更安全的事实。

最好的解决方法是在 Ruby 代码中使用用另一种语言（例如 C、C++、Fortran）编写的目标模块。这些可以完成繁重的工作，您的脚本可以专注于更高级别的协调问题。

【讨论】：

比较通常是用 Java、C#、Python，也许是 Perl 而不是 C++。
当然。但我可以向您（作为 Tcl 的开发人员）保证，人们会总是不公平地将您与其他语言进行比较。解决方法是将那些其他语言用于您拼接在一起的组件；用一种语言完成这一切有点像使用一个工具来完成所有任务。如果你只有一把锤子，那么一切看起来都像拇指。
在需要时使用外语模块的好主意
>> 无条件地说“Ruby 很慢”
你知道他们对谎言、该死的谎言和基准的评价。 ;-)

【解决方案9】：

首先，你关心别人对你喜欢的语言的看法吗？当它完成它必须做的工作时，你就没事了。

OO 并不是执行代码的最快方式，但它确实有助于创建代码。聪明的代码总是比愚蠢的代码和无用的循环快。我是一名 DBA，看到很多这些无用的循环，删除它们，使用更好的代码和查询，应用程序更快，更快。你关心最后一微秒吗？您的语言可能针对速度进行了优化，其他语言只是完成他们必须做的工作，并且可以由许多不同的程序员维护。

这一切都只是一个选择。

【讨论】：

【解决方案10】：

显然，谈到速度 Ruby 的失败。尽管基准测试表明 Ruby 并不比 PHP 慢多少。但作为回报，您将获得易于维护的 DRY 代码，这是各种语言的所有框架中最好的。

对于一个小项目，你不会感到任何缓慢（我的意思是直到像

对于更大的项目，为资源付费是有回报的，而且比开发人员的工资便宜。此外，在 RoR 上编写代码比其他任何方式都要快。

在 2014 年，您所说的这种速度差异对于大多数网站来说都是微不足道的。

【讨论】：

【解决方案11】：

处理 Ruby 在 Web 应用程序中的性能的方法与任何其他编程语言相同：

架构

这在 Rails 中比在大多数其他 Web 框架中更容易做到。

在应用程序级别，通过缓存应该缓存的任何内容并以智能方式管理对 DB 的访问（因为对于大多数 WEB 而言，瓶颈通常在“DB”访问应用程序）。

Rails 让解决这些问题变得非常容易和自然。 There are several abstractions for caching data, pages and fragments，还有非常好的抽象来以优化和可重用的方式处理 SQL 部分（Active Record 和 AREL）。

这就是为什么这么多用速度更快但表达力不强的语言（如 php）编写的应用程序最终比 Ruby 对应物慢的原因。使用这些语言处理缓存和查询并不像使用 Ruby 那样简单和优雅。

在基础设施级别，考虑负载平衡和所有我碰巧不太了解的东西是合理的。我会通过雇佣一些平台作为服务提供商来解决这个问题，比如Heroku 或Engine Yard。反正。部署带有负载平衡的 Rails 可能并不难。

【讨论】：

【解决方案12】：

人们说 Ruby 很慢，因为他们将 Ruby 程序与用其他语言编写的程序进行比较。也许您编写的程序不需要更快。也许对于您编写的程序而言，Ruby 并不是瓶颈，它会减慢速度。

Ruby 2.1 compared to Javascript V8

Ruby 2.1 compared to ordinary Lua

Ruby 2.1 compared to Python 3

【讨论】：

【解决方案13】：

性能几乎总是与良好的设计和优化的数据库交互有关。 Ruby 可以快速完成大多数网站所需的工作，尤其是更新的版本；开发速度和易于维护为成本和保持客户满意度提供了巨大的回报。我发现 JAVA 对于某些任务的执行性能很慢，并且考虑到在 JAVA 中开发的难度，许多开发人员创建的应用程序速度很慢，而不管基准测试中展示的理论速度能力如何（基准通常被设计为显示特定和狭窄的能力）。当我需要不太适合我的数据库功能的密集处理时，我会根据平台为这些任务选择 C 或 Objective-C 或其他一些真正高性能的编译语言。如果我需要创建数据库 Web 应用程序，我会使用 RoR 或有时使用 C# ASP.NET，具体取决于其他要求；因为所有平台都有优点和缺点。您的应用程序所做的事情的执行速度很重要，但毕竟，如果语言的一个狭窄方面的执行性能才是最重要的；那么我可能仍然在使用汇编语言。

【讨论】：

【解决方案14】：

Ruby 在提高开发人员生产力方面表现出色。由于缺乏类型，Ruby 天生就迫使测试驱动开发。 Ruby 在用作 C 库的高级包装器时表现良好。当通过 JVM 或 Rbx VM JIT 编译为机器代码时，Ruby 在长时间运行的进程中也表现良好。当需要使用纯 Ruby 代码在短时间内处理数字时，Ruby 的性能不佳。

【讨论】：