我非常热衷于开发我的第一个 Ruby 应用程序,因为我的公司终于在内部祝福了它的使用。
在我读到的关于 Ruby 直到 v1.8 的所有内容中,从来没有任何关于性能的正面评价,但我没有发现关于 1.9 版本的任何内容。我看到的关于 1.8 的最后一个数字比几乎所有的东西都要慢得多,所以我希望这个问题在 1.9 中得到解决。
性能有显着提高吗?是否有一些具体的事情可以用 Ruby 应用程序完成(或要避免的事情)以将性能保持在最佳水平?
我非常热衷于开发我的第一个 Ruby 应用程序,因为我的公司终于在内部祝福了它的使用。
在我读到的关于 Ruby 直到 v1.8 的所有内容中,从来没有任何关于性能的正面评价,但我没有发现关于 1.9 版本的任何内容。我看到的关于 1.8 的最后一个数字比几乎所有的东西都要慢得多,所以我希望这个问题在 1.9 中得到解决。
性能有显着提高吗?是否有一些具体的事情可以用 Ruby 应用程序完成(或要避免的事情)以将性能保持在最佳水平?
在http://www.rubychan.de/share/yarv_speedups.html上有一些 1.8 和 1.9 的基准。总的来说,在大多数情况下,1.9 看起来要快得多。
如果可伸缩性和性能对您来说真的很重要,您还可以查看Ruby Enterprise Edition。它是 Ruby 解释器的自定义实现,应该在内存分配和垃圾收集方面做得更好。我没有看到任何将它直接与 JRuby 进行比较的客观指标,但我听到的所有轶事证据都非常非常好。
这来自创建Passenger(又名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 Ruby 更好。
我赞成使用Passenger的建议-它使Rails应用程序的部署和管理变得微不足道