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