我喜欢Ruby on Rails，我将它用于我的所有Web开发项目。几年前，有很多关于Rails是记忆力的讨论以及它如何不能很好地扩展，但这些建议被Gregg Pollack解释了 here。 < / p>
最近，我听说有人说Ruby本身很慢。
我发现Ruby并不慢，但是我只是用它来制作简单的CRUD应用程序和公司博客。在我发现Ruby变慢之前，我需要做什么样的项目？或者这种缓慢只会影响所有编程语言？
如果你想处理这种“缓慢”，你作为Ruby程序员的选择是什么？
哪个版本的Ruby最适合像Stack Overflow这样的应用程序，速度至关重要且流量很大？
这些问题是主观的，我意识到架构设置（EC2与独立服务器等）有很大的不同，但我想听听人们对Ruby慢慢的看法。
最后，我找不到关于Ruby 2.0的很多新闻 - 我认为我们距离那个好几年了？
答案 0 :(得分：180)
为什么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开发人员能够非常快速地开发应用程序。
答案 1 :(得分：120)
首先，相对于更慢？ C？蟒蛇？让我们<{>}获取一些数字 Computer Language Benchmarks Game：
为什么Ruby被认为很慢？
取决于你问谁。你可以被告知：
但是，那么又是什么呢？与C相比，Ruby 1.9的速度与Python和PHP一样快（在3倍的性能因素内）（可以快300倍），所以上述（除了线程注意事项，应用程序在很大程度上取决于这个方面） ）主要是学术性的。
如果你想处理这种“慢”，你作为Ruby程序员有什么选择？
写入可伸缩性并在其上投入更多硬件（例如内存）
哪种版本的Ruby最适合像Stack Overflow这样的应用程序，其中速度至关重要且流量很大？
答案 2 :(得分：59)
这是Rails的创建者David Heinemeier Hansson必须说的：
Rails [Ruby]绝大多数 的Web应用程序足够快。我们 让网站有数百万的动态 每日页面浏览量。如果你结束了 与雅虎或亚马逊前线 页面，它不太可能 ANY中的现成框架 语言对你有好处。你会 可能要自己滚动。但 当然，我也想要免费的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开始比语言的速度更重要，所以我将专注于优化它。
答案 3 :(得分：34)
编写代码很慢。阅读代码很慢。查找和修复错误很慢。添加功能和增强功能很慢。任何改进的东西都是胜利。执行性能很少是一个问题。
答案 4 :(得分：15)
答案很简单：人们说红宝石很慢，因为基于与其他语言的测量比较， 慢。但请记住，“慢”是相对的。通常，ruby和其他“慢”语言足够快。
答案 5 :(得分：5)
Joel on Software - Ruby Performance Revisited 很好地解释了它。可能会过时......
我建议你坚持使用它，因为你习惯了Ruby on Rails，
如果您遇到性能问题，可能会重新考虑使用不同的语言和框架。
在这种情况下，我真的建议C＃使用ASP.NET MVC 2，对CRUD应用程序非常有用。
答案 6 :(得分：4)
我认为Ruby很慢，因为没有花费太多精力来使解释器更快。同样适用于Python。 Smalltalk与Ruby或Python一样动态，但在一定程度上表现更好，请参阅http://benchmarksgame.alioth.debian.org。由于Smalltalk或多或少被Java和C＃取代（至少在10年前），因此不再为它进行性能优化工作，Smalltalk仍然比Ruby和Python更快。 Xerox Parc和OTI / IBM的员工有钱支付那些致力于使Smalltalk更快的人。我不明白的是，为什么谷歌不会花这笔钱来加快Python的速度，因为他们是一家大型的Python商店。相反，他们花钱去开发像Go这样的语言......
答案 7 :(得分：2)
首先，您是否关心别人对您喜欢的语言的看法？当它完成它必须做的工作时，你没事。
OO不是执行代码的最快方法，但它确实有助于创建代码。智能代码总是比哑代码和无用循环更快。我是一名DBA，看到很多这些无用的循环，删除它们，使用更好的代码和查询，应用程序更快，更快。你关心最后一微秒吗？您可能拥有针对速度优化的语言，其他人只需完成他们必须完成的工作，并且可以由许多不同的程序员进行维护。
这只是一个选择。
答案 8 :(得分：2)
显然，谈论速度Ruby失败。尽管基准测试表明Ruby并不比PHP慢得多。但作为回报，您将获得易于维护的DRY代码，这是各种语言中所有框架中最好的。
对于一个小项目，你不会感到任何缓慢（我的意思是直到喜欢＆lt; 50K用户），因为代码中没有使用复杂的计算，只是主流的东西。
对于一个更大的项目，支付资源是有回报的，并且比开发商的工资便宜。此外，在RoR上编写代码比其他代码快得多。
2014年，您所谈论的这种速度差异的大小对大多数网站来说都是微不足道的。
答案 9 :(得分：2)
处理Ruby在Web应用程序中的性能的方法与任何其他编程语言相同：
<强>建筑
这在Rails中比在大多数其他Web框架中更容易实现。
在应用程序级，通过缓存任何应该缓存的内容并通过智能方式管理对DB的访问（因为瓶颈通常是对大多数WEB的“DB”访问应用程序）。
Rails使解决这些问题变得非常容易和自然。 There are several abstractions for caching data, pages and fragments，以优化和可重用的方式（Active Record和AREL）处理SQL部分也有非常好的抽象。
这就是为什么如此多的应用程序以更快和不那么具有表现力的语言（如php）编写的应用程序最终比Ruby对应程序慢。与使用Ruby相比，使用这些语言来处理缓存和查询并不是那么容易和优雅。
在基础架构级，考虑负载平衡以及我不太了解的所有内容是合理的。我通过雇用某个平台作为服务提供商来解决这个问题，例如Heroku或Engine Yard。无论如何。部署具有负载平衡的rails可能并不是很难。
答案 10 :(得分：1)
Ruby在许多易于测量的任务中比C ++慢（例如，执行严重依赖于浮点的代码）。这并不是很令人惊讶，但足以说明某些人没有资格就说“Ruby很慢”。他们不认为编写Ruby代码比C ++更容易，更安全。
最好的解决方法是在Ruby代码中使用用其他语言编写的目标模块（例如，C，C ++，Fortran）。那些可以解决繁重问题，你的脚本可以专注于更高层次的协调问题。
答案 11 :(得分：0)
人们说Ruby很慢，因为他们将Ruby程序与用其他语言编写的程序进行比较。也许您编写的程序不需要更快。也许对于你编写的程序而言，Ruby不是瓶颈，这会减慢速度。
Ruby 2.1 compared to Javascript V8
答案 12 :(得分：0)
性能几乎总是关于良好的设计和优化的数据库交互。 Ruby可以很快地完成大多数网站的需求，特别是更新的版本;而且开发速度和易维护性在成本和保持客户满意度方面提供了巨大的回报。我发现JAVA对某些任务的执行性能较慢，而且考虑到在JAVA中开发的难度，许多开发人员创建了缓慢的应用程序，而不管基准测试中所显示的理论速度能力（基准测试通常被设计为显示特定的和狭窄的能力）。当我需要不太适合我数据库功能的密集处理时，我会根据平台为这些任务选择C或Objective-C或其他一些真正高性能的编译语言。如果我需要创建一个数据库Web应用程序，我会根据其他要求使用RoR或有时使用C＃ASP.NET;因为所有平台都有优点和缺点。应用程序所执行的操作的执行速度很重要，但毕竟，如果语言的一个狭窄方面的执行性能非常重要;然后我可能仍然会使用汇编语言来处理所有事情。
答案 13 :(得分：-5)
Ruby在开发人员工作效率方面表现良好。由于缺乏类型，Ruby本质上迫使测试驱动开发。当用作C库的高级包装器时，Ruby表现良好。当通过JVM或Rbx VM对JIT编译为机器代码时，Ruby在长时间运行的进程中也表现良好。当需要使用纯ruby代码在短时间内处理数字时，Ruby表现不佳。