就性能而言,目前 Ruby 1.9.1 和 JRuby 领导着 Ruby 的实现。然而由于种种原因,转到这两个实现中的任何一个都不是那么容易的事情,因为 Ruby 1.9.x 在有些地方与 1.8.7 不兼容,同时 JRuby 仍旧缺乏一些使用本地扩展的 Ruby 库。由于这个原因,MRI 1.8.x 还会继续存在一段时间,那么我们可能对其性能的改进产生兴趣。
目前 Brent Roman 在一定程度上改进了 Ruby 1.8.x MRI 的性能。他正不断尝试着修复 Ruby 中的内存泄漏问题。
基本的技术就是对 Kurt Stephens 所建议的一个问题的精化。它不仅消除了这行代码的泄漏问题:
loop {@x=callcc{|c|c}}
还消除了我们多线程机器人技术应用中的泄漏问题。过去我们所使用的 Ruby 进程在运行一天后常常达到 20+MB,而现在已经降到了 10MB 以下。
正如其所示,泄漏是由 GCC 的优化所导致的:它与 Ruby 的旧式 GC 的交互很差劲:
垃圾收集器的内存泄漏问题并不是它本身的错误。问题在于“C”机器栈(machine stack)中充满了对象引用。其主要原因是由于 gcc 编译器创建了过多大的 stack frame 而又没有对其初始化。用在 Ruby 解释器的核心递归表达式程序中的某些“C”构造会生成特别大而又稀疏的 stack frame。函数 rb_eval() 就是最差劲的一个,它会为每次调用都创建 KB 大小的 stack frame,而其又会调用自身几百次。这导致栈的容量急剧膨胀,经常充满了不再使用而又无法移除的对象引用。
Brent提供了一些修复(针对Ruby 1.8.7-patlevel72),目的在于解决这些问题。
当运行在真实世界的Rails 应用上时,测试报告表明该修复对速度的提升效果很明显。同时也报告了一些问题,让我们对其拭目以待吧。
这些修复是开源(Ruby)社区对MRI 改进的又一个证明。 Mod_rails (或 REE) 已经是一个佐证了,它使得 MRI 的垃圾收集器更加友好(参见相关新闻以了解更多)。
MRI 的性能在很大程度上取决于它的编译方式。
今年你还打算继续使用Ruby 1.8.x 么?如果是的话,理由呢?
查看英文原文: New Patches for 1.8.x Fix Memory Leaks And Improve Performance
评论