我非常热衷于开发我的第一个 Ruby 应用程序，因为我的公司终于在内部使用它。
在我读到的关于 Ruby 直到 v1.8 的所有内容中，从来没有任何关于性能的正面评价，但我没有发现任何关于 1.9 版本的信息。我看到的关于 1.8 的最后一个数字比几乎所有的东西都要慢得多，所以我希望在 1.9 中解决这个问题。
性能有显着提高吗？是否有一些具体的事情可以使用 Ruby 应用程序完成（或要避免的事情）以将性能保持在可能的最佳水平？
【问题讨论】：
标签： ruby performance ruby-1.9
http://www.rubychan.de/share/yarv_speedups.html 有一些 1.8 与 1.9 的基准。总的来说，在大多数情况下，1.9 看起来要快得多。
【讨论】：
如果可扩展性和性能对您来说真的很重要，您还可以查看Ruby Enterprise Edition。它是 Ruby 解释器的自定义实现，应该在内存分配和垃圾收集方面做得更好。我没有看到任何将它直接与 JRuby 进行比较的客观指标，但我所听到的所有轶事证据都非常非常好。
这来自创建 Passenger (aka mod_rails) 的同一家公司，如果您决定不采用 JRuby 路线，您绝对应该将其作为 Rails 部署解决方案进行检查。
【讨论】：
Matz ruby 1.8.6 在性能方面要慢得多，而 1.9 和 JRuby 做了很多工作来加快它。但是性能并不会阻止您在 Web 应用程序中做任何您想做的事情。有许多大型 Ruby on Rails 网站可以很好地使用“较慢的解释”语言。当您扩展 Web 应用程序时，比您编写它的语言的速度更紧迫的性能问题。
【讨论】：
我实际上听说过关于 JVM 实现 JRuby 的性能非常好。完全是轶事，但也许值得研究。
【讨论】：
查看 Addison Wesley Professional 的“编写高效的 Ruby 代码”：
http://safari.oreilly.com/9780321540034
我在这个简短的工作中发现了一些非常有用和有趣的见解。如果您注册 10 天免费试用版，则可以免费阅读。 （它有 50 页，试用版可让您 (AFAIR) 获得 100 次页面浏览量。）
【讨论】：
我不是 Ruby 程序员，但我最近非常密切地参与了 JRuby 部署，因此可以得出一些结论。不要对 JRuby 的性能抱有太大的期望。在解释模式下，它似乎在 C Ruby 的范围内。 JIT 模式可能更快，但仅在理论上。在实践中，我们在 Glassfish 上尝试了 JIT 模式，以便在中型服务器（双核，8GB RAM）上运行一个大小适中的 Rails 应用程序。事实是，JITting 花费了非常令人难以置信的时间，以至于服务器需要 20-30 分钟才能响应第一个请求。内存使用量是天文数字，分析不起作用，因为整个系统在附加分析器的情况下停止运行。
底线：JRuby 有其优点（多线程、可靠的平台、易于 Java 集成），但鉴于解释模式是唯一在实践中对我们有用的模式，预计它在性能方面不会比 C 更好红宝石。
【讨论】：
我反对使用 Passenger 的建议 - 它使 Rails 应用程序的部署和管理变得轻而易举
【讨论】：