为什么人们说Ruby很慢？

Question

为什么人们说Ruby很慢？

ste*_*och 184 ruby performance

我喜欢Ruby on Rails,我将它用于我的所有Web开发项目.几年前,有很多人谈论Rails是一种记忆生长以及它如何不能很好地扩展,但这些建议在这里由Gregg Pollack解决.

最近,我听说有人说Ruby本身很慢.

为什么Ruby被认为很慢？

我发现Ruby不会很慢,但是我只是用它来制作简单的CRUD应用程序和公司博客.在我发现Ruby变慢之前,我需要做什么样的项目？或者这种缓慢只是影响所有编程语言的东西？

如果你想处理这种"慢",你作为Ruby程序员有什么选择？
哪个版本的Ruby最适合像Stack Overflow这样的应用程序,其中速度至关重要且流量很大？

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

最后,我找不到关于Ruby 2.0的很多新闻 - 我认为它们离我们好几年了？

Answer 1

Jay*_*dse 184

为什么Ruby被认为很慢？

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

我发现Ruby不会很慢,但是我只是用它来制作简单的CRUD应用程序和公司博客.在我发现Ruby变慢之前,我需要做什么样的项目？或者这种缓慢只是影响所有编程语言的东西？

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缓存,内存缓存,Ajax,客户端缓存等等.这些东西都不是Ruby.

最后,我找不到关于Ruby 2.0的很多新闻 - 我认为它们离我们好几年了？

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

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

语言不慢或快,它们的实现,解释器和编译器是:) (13认同)
经过深思熟虑后,我认为这是最好的答案.谢谢,我喜欢关于信号处理应用程序的类比.在所有这些有用的答案之后,现在可以更容易地看到人们正在谈论的内容. (3认同)
我使用Ruby 2.1的经验是它比在Ruby 2.0中运行的同一个应用程序快25% (3认同)
@ZelphirKaltstahl 我迟到了这个话题，但我想对你的评论发表评论:)我同意解释器和编译器在程序的执行方式上发挥着重要作用，但语言也非常重要。Ruby 和 Python 等动态语言比静态类型语言慢，仅仅是因为它们在运行时需要大量类型检查。猴子补丁很酷，但很昂贵。 (2认同)

Answer 2

vla*_*adr 121

首先,相对于什么慢？C？蟒蛇？让我们在计算机语言基准游戏中获得一些数字:

Ruby 1.9与Python3在同一数量级内
Ruby 1.9与PHP在同一数量级内
Ruby 1.9与Java 6服务器的速度要慢两个数量级!
Ruby 1.9 vs. C(gcc)慢了两个数量级!
...

为什么Ruby被认为很慢？

取决于你问谁.你可以被告知:

Ruby是一种解释型语言,解释型语言往往比编译语言慢
Ruby使用垃圾收集(虽然C#,它也使用垃圾收集,比Ruby,Python,PHP等提出两个数量级,在更多的算法,更少的内存分配密集型基准测试中)
Ruby 方法调用很慢(尽管由于鸭子类型,它们可以说比强类型解释语言更快)
Ruby(JRuby除外)不支持真正的多线程
等等

但是,那么又是什么呢？与C相比,Ruby 1.9的速度与Python和PHP一样快(在3倍的性能因素内)(可以快300倍),所以上述(除了线程注意事项,应用程序在很大程度上取决于这个方面) )主要是学术性的.

如果你想处理这种"慢",你作为Ruby程序员有什么选择？

写入可伸缩性并在其上投入更多硬件(例如内存)

哪个版本的Ruby最适合像Stack Overflow这样的应用程序,其中速度至关重要且流量很大？

那么,REE(与乘客相结合)将是一个非常好的候选人.

>>在相同的数量级内<<如果你活到7岁或活到69岁,那么它在同一数量级内.这种差异是微不足道的吗？ (11认同)
@igouy,我不了解你,但我不是一个衡量我的执行速度的生命周期的程序.我关心执行速度的地方,例如,HTTP响应渲染时间.我知道我不会注意到7ms和69ms渲染时间之间的差异(特别是当骑在130ms网络延迟之上时).我知道我会注意到7毫秒和700毫秒之间的差异,我将特别注意7毫秒和7秒之间的差异 - 但不是,不是7毫秒到69毫秒之间. (9认同)
@vladr,70ms或700ms怎么样？你能注意到这种差异吗？ (2认同)

Answer 3

rjh*_*rjh 60

以下是Rails的创建者David Heinemeier Hansson所说的:

Rails [Ruby]适用于绝大多数Web应用程序Fast Fast.我们的网站每天都会进行数百万次动态页面浏览.如果您最终使用雅虎或亚马逊的首页,那么任何语言中的现成框架都不太可能对您有所帮助.你可能不得不自己动手.但是可以肯定的是,我也想要免费的CPU周期.我碰巧更关心自由开发者周期,并愿意为后者交易前者.

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

Ruby 1.9是一个超过1.8的巨大改进.Ruby 1.8的最大问题是它的解释性质(没有字节码,没有编译),并且方法调用(Ruby中最常见的操作之一)特别慢.

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

如果我在Ruby中编写一个流行的Web应用程序,我的重点将放在缓存上.无论您使用何种语言,缓存页面都会将该页面的处理时间缩短为零.对于Web应用程序,数据库开销和其他I/O开始比语言的速度更重要,所以我将专注于优化它.

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

Answer 4

Jam*_*olk 34

编写代码很慢.阅读代码很慢.查找和修复错误很慢.添加功能和增强功能很慢.任何改进的东西都是胜利.执行性能很少是一个问题.

@GregS:如果影响可用性,执行性能总是*问题.没错,从纯数字的角度来看,在一秒或三秒内扫描一个字符串的xml文件并不重要,但是当你谈论一个面向用户的应用程序时,几秒钟的差异会对可用性产生很大的影响. (27认同)
到目前为止,我的记录是在一天的工作中为公司节省了30,000美元/年.他们的工程师认为让云计算算法计算每次迭代完成的任务数量更具可读性,从而导致n!对20,000多个工作单位的工作进行查询.更改它以检查是否有1个工作项被丢弃到n个查询,并将账单从130美元/天减少到20美元/天.懒惰的程序员让我赚钱.请鼓励更多懒惰的程序员. (15认同)
你刚刚发表评论很有意思......我已经转移到另一家公司,我们不得不将十五名开发人员从功能和性能上拉下来,因为一家大型美国银行拒绝签署数百万美元的合同,直到系统可以处理他们的负担.他们喜欢我们的功能,而不是他们的表现速度.如果你长时间忽略性能,那么你拥有什么功能并不重要,因为它们会非常慢*. (10认同)
@Ajax:不,我打赌这是你赢得的个性. (5认同)
执行绩效始终是一个问题,我们所谈论的问题究竟有多少.在用户停止购买应用程序之前,您可以在移动电话上运行多少解释代码,因为它会杀死电池？在关闭广告之前,用户等待您的网页加载多长时间会剥夺您的广告收入？回答这些问题以及执行绩效的重要性. (4认同)
@Bryan:同意,但我支持我的"很少"的资格. (3认同)
@Ajax:我写的任何内容都没有鼓励懒惰的程序员.你已经读过你想要阅读的内容. (3认同)
@dev调优Ajax所做的是算法上的改进。通过更改渐近线，它为少量工作节省了大量资源。算法改进通常是值得的。 (2认同)

Answer 5

Bry*_*ley 15

答案很简单:人们说红宝石很慢,因为根据与其他语言的测量比较,它很慢.但请记住,"慢"是相对的.通常,ruby和其他"慢"语言足够快.

>>它仍然很快就符合我的要求<<对于一切不需要快速的东西来说它足够快:-) (11认同)

Answer 6

Tam*_*man 5

关于软件的Joel-再探Ruby性能很好地解释了这一点。可能会过时了...

我建议您像在Ruby on Rails上一样坚持使用它，
如果遇到性能问题，您可能会重新考虑使用其他语言和框架。

在那种情况下，我真的建议将C＃与ASP.NET MVC 2配合使用，对于CRUD应用程序非常有效。

归档时间：	15 年，11 月前
查看次数：	127922 次
最近记录：	9 年，6 月前