Ruby性能综述：Ruby 1.9.1在实际应用中的性能、GC vs EventMachine及Ruby编译器

使用Ruby 1.9.1的一个重要原因就是其显著提高的性能。新的基准结果来自于现有的应用并比较了1.8.x、JRuby及1.9.1：

我们将Acunote（在线的企业项目管理和Scrum软件）移植到了JRuby和Ruby 1.9上并运行了性能基准测试集。

Ruby 1.9.1和JRuby的性能都大大超越了1.8.6，而1.9.1又领先于JRuby，虽然我们可以通过一些命令行参数来改进JRuby的性能，但实际情况差不多如此。

1.9.1的性能改进不仅仅来自于更快的VM，一些新特性也起到了很大的作用。Muhammed Ali向我们展示了如何通过Ruby 1.9.1的Fibers来度量Web应用。另一方面，Muhammed还指出了1.9.1中的Object#extend所导致的内存泄漏问题。

与此同时，1.8.6仍旧是某些项目的不二之选，这是由于1.9.1缺少了一些库的支持。由于这个原因，很多人热衷于修复1.8.6的某些瓶颈。Joe Damato在其博客上发表了一些文章谈到了这些问题。比如，他谈到了--enable-pthread背后的事情以及为何禁用该设定会提升30%的性能。在另一篇文章中，Joe和Aman Gupta探索了Ruby GC的一个问题并给出了一个小修复来解决GC和EventMachine的问题：

* 由于极大地降低了stack frame的大小，因此将GC的速度提升了2、3倍。

* 修复了EventMachine中的一个公开bug——通过Epoll来使用线程会极大地降低应用的速度。其原因是每个线程都会继承一个~800,000字节的stack，每次上下文切换时都会对其进行复制。

* 在使用Sinatra+Thin+Epoll+Threads时会将请求数从每秒500个提升到7000个，太爽了。

最后，Viktor Hokstad正在撰写一系列文章讲述如何编写Ruby编译器。最近的一篇谈到了怎样才能让Ruby更快。

查看英文原文：Ruby Performance Roundup: Ruby 1.9.1 Real World Performance, GC vs EventMachine, Ruby Compiler