为什么大家都说 Ruby 反应迟钝?

我喜欢 Ruby on Rails,并且我在所有的 web 开发项目中都使用它。几年前有很多关于 Rails 占用大量内存的讨论,以及它如何不能很好地扩展,但 Gregg Pollack 这里。将这些建议抛诸脑后

但是最近,我听到人们说 Ruby 本身就很慢。

  • 为什么 Ruby 被认为是慢的?

我并不觉得 Ruby 很慢,但话说回来,我只是用它来做一些简单的 CRUD 应用程序和公司博客。在我发现 Ruby 变慢之前,我需要做哪些项目?或者这种缓慢只是影响所有编程语言的某种因素?

  • 作为一个 Ruby 程序员,如果你想处理这种“缓慢”,你有什么选择?

  • 哪个版本的 Ruby 最适合 Stack Overflow 这样的应用程序,因为它的速度很关键,而且流量很大?

这些问题是主观的,我知道架构设置(EC2与独立服务器等)有很大的不同,但我想听听人们对 Ruby 速度慢的看法。

最后,我找不到太多关于 Ruby 2.0的新闻-我想我们离那个还有好几年吧?

138526 次浏览

编写代码很慢。读代码很慢。发现和修复 bug 是很慢的。添加特性和增强非常缓慢。任何比前一次进步的都是胜利。执行性能很少是一个问题。

以下是 Rails 的创始人 达维德·海涅迈尔·汉松所说的:

Rails [ Ruby ]是为大多数人准备的 网络应用程序的速度足够快。我们 有数百万的动态网站 每天的页面浏览量。如果你最终 与雅虎或亚马逊合作 Page 任何现成的框架 语言对你有好处 可能得自己卷了,但是 当然,我也想要免费的 CPU 周期 只是碰巧更关心 免费开发周期,并愿意 用前者换取后者。

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

Ruby 1.9是对1.8的巨大改进。Ruby 1.8最大的问题在于它的解释特性(没有字节码,没有编译) ,而方法调用(Ruby 中最常见的操作之一)尤其缓慢。

在 Ruby 中,几乎所有的东西都是方法查找——添加两个数字,索引一个数组,这些都无济于事。在其他语言公开的地方(Python 的 __add__方法,Perl 的 overload.pm) ,Ruby 在所有情况下都是纯面向对象的,如果编译器/解释器不够聪明,这可能会影响性能。

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

Ruby 在许多易于测量的任务上比 C + + 慢(例如,编写严重依赖于浮点数的代码)。这并不十分令人惊讶,但是对于一些人来说,这已经足够证明他们可以毫无保留地说“ Ruby 很慢”了。他们没有考虑到这样一个事实,即编写 Ruby 代码要比 C + + 容易和安全得多。

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

首先,慢一点? C? Python? 让我们来看 拿到一些数据计算机语言基准游戏:

为什么 Ruby 被认为是慢的?

这取决于你问的是谁,你可能会被告知:

  • Ruby 是 直译语言,解释语言往往比编译语言慢
  • Ruby 使用的是 垃圾回收(尽管也使用垃圾收集的 C # 在上述算法较多、内存分配密集程度较低的基准测试中,比 Ruby、 Python、 PHP 等领先了两个数量级)
  • Ruby方法调用很慢(尽管由于 Duck 类型化,它们可能比强类型解释语言更快)
  • Ruby (JRuby 除外) 不支持 < strong > 真正的多线程
  • 等等。

但是,话说回来,为什么这么慢呢?与 C 相比,Ruby 1.9的速度大约是 Python 和 PHP 的速度(在3倍的性能系数内)(C 的速度可以快上300倍) ,所以上面的(除了线程方面的考虑,如果你的应用程序严重依赖于这方面的话)在很大程度上是学术性的。

作为一个 Ruby 程序员,如果你想处理这种“缓慢”,你有什么选择?

为了可伸缩性而编写代码,并在 (例如内存)上投入更多的硬件

哪个版本的 Ruby 最适合 Stack Overflow 这样的应用程序,因为它的速度很关键,而且流量很大?

翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳是个不错的选择。

Joel 关于软件-Ruby 性能的回顾 很好地解释了它,虽然可能已经过时了。

我建议你还是坚持使用 Ruby on Rails 吧,
如果遇到性能问题,您可能会重新考虑使用不同的语言和框架。

在这种情况下,我真的建议 C # 与 NET MVC 2,非常适合 CRUD 应用程序。

答案很简单: 人们说 Ruby 很慢是因为它的 比其他语言慢。不过,请记住,“缓慢”是相对的。通常情况下,Ruby 和其他“慢”语言已经足够快了。

首先,你在乎别人怎么评价你喜欢的语言吗?当它完成它的工作时,你就没事了。

OO 并不是执行代码的最快方法,但它确实有助于创建代码。智能代码总是比愚蠢的代码和无用的循环快。我是一名 DBA,看到了很多无用的循环,放弃它们,使用更好的代码和查询,应用程序更快,更快。你在乎最后一微秒吗?您可能有为速度而优化的语言,其他语言只是做它们必须做的工作,并且可以由许多不同的程序员维护。

这只是一个选择。

人们说 Ruby 很慢是因为他们把 Ruby 程序和其他语言编写的程序进行比较。也许你写的程序不需要更快。也许对于你编写的程序来说,Ruby 并不是 瓶颈,因为它减慢了速度。

Ruby 2.1与 Javascript V8的比较

Ruby 2.1与普通 Lua 相比

Ruby 2.1与 Python 3相比

为什么 Ruby 被认为是慢的?

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

我不觉得露比是个慢性子 再说一次,我只是用它来 简单的 CRUD 应用程序和公司博客。 我需要什么样的项目 在我发现露比变成 缓慢? 还是这种缓慢只是 影响所有程序的东西 语言?

Ruby 可能无法很好地为您编写实时数字信号处理应用程序或任何类型的实时控制系统。Ruby (使用今天的虚拟机)可能会被智能手机等资源受限的计算机噎死。

请记住,你的 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-我想我们是好兄弟 几年之后呢?

大多数人都在等待 Ruby1.9.1,我自己也在等待 Ruby1.9.1上的 Rails 3.1和 JRuby。

最后,请记住,许多开发人员选择 Ruby 是因为与其他语言相比,它让编程变得更加愉快,而且 Ruby with Rails 使得熟练的 Web 开发人员能够非常快速地开发应用程序。

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

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

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

对于一个小型项目,您不会感觉到任何缓慢(我的意思是直到像 < 50K 用户) ,因为代码中没有使用复杂的计算,只有主流的东西。

对于一个更大的项目来说,支付资源是有回报的,而且比开发人员的工资便宜。此外,在 RoR 上编写代码比其他任何代码都要快得多。

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

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

建筑

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

在应用程序级别 ,通过缓存任何应该被缓存的东西,并通过智能方式管理对数据库的访问(因为大多数 WEB 应用程序的瓶颈通常是“ DB”访问)。

Rails 使得解决这些问题变得非常容易和自然。还有非常好的抽象,可以用优化的和可重用的方式(活动记录AREL)处理 SQL 部分。

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

在基础设施层面,考虑负载平衡和所有我碰巧不太了解的东西是合理的。我会将这个问题外包出去,聘请一些平台作为服务提供商,如 你好引擎站。不管怎样。部署具有负载平衡的轨道可能并不是很难做到。

我认为 Ruby 的速度很慢,因为在使解释器更快方面并没有花费太多的精力。Python 也是如此。Smalltalk 与 Ruby 或 Python 一样具有动态性,但性能要好上一大截,参见 http://benchmarksgame.alioth.debian.org。由于 Smalltalk 或多或少被 Java 和 C # (至少10年前)所取代,因此没有更多的性能优化工作可做,而且 Smalltalk 仍然比 Ruby 和 Python 快得多。施乐帕克研究中心和 OTI/IBM 的人有钱雇佣那些致力于让 Smalltalk 更快的人。我不明白的是,谷歌为什么不花钱让 Python 变得更快,因为他们是一个巨大的 Python 商店。相反,他们花钱开发像围棋这样的语言..。