1.8.x 的新修复解决了内存泄漏问题并改进了性能

就性能而言，目前 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