再探Ruby效能

这篇文字于2006年9月12日张贴在约耳谈软体首页。

Jack Herrington针对Ruby on Rails的效能议题写电邮给我，信上写着：

我同意你关于Unicode的说法，也同意Rails需要时间发展。不过我用了一堆的Web技术，每个都有问题。 我倒是不同意你对可扩充性（可伸缩性）的说法。我不认为滑轨有那种其他技术所没有，而且无法克服的扩充性问题。 我希望你至少能把你对扩充性的说法讲得更清楚。告诉我们是什么样的扩充性问题。即使我们无法替你解决，整个社群还是能由你的经验有所收获。

David Heinemeier Hansson写着：

轨对绝大多数的网络应用而言已经够快了。我们有每天处理数百万个动态网页的网站。如果你的目标是做出像雅虎或亚马逊的首页，大概没有基于任何语言的现成框架能做得好。你很可能得自己来。不过当然啦，我也是喜欢让CPU闲一点。不过恰巧的是，我更希望能让开发者更闲，所以愿意牺牲前者来获得后者。

顺便澄清一下，我在意的是Ruby而不是** Rails **的效能。原因如下：

我看过许多拿的Java（对我而言不算快）之类的字节代码语言和红宝石效能对照的比较，而且我也看到很多效能报告声称红宝石[慢十倍]（HTTP：//www.pankaj- k.net/archives/2005/11/ruby_or_java_a.html）或[慢五十倍（http://fishbowl.pastiche.org/2004/10/28/ruby_performance）云云。除了少数的网志鬼扯外，红宝石在[电脑语言对抗评比]（http://shootout.alioth.debian.org/）上几乎是稳吊车尾了。

我并不知道Ruby实作的细节，不过我猜最大的问题大概是在晚期连结（late binding）以及最主要的鸭子型别处理（duck 打字）吧，有了后者就不能用型别参考或是强型别处理。这表示函数的呼叫一定会慢，因为你永远没有办法把函数呼叫编译成单一个x86的指令集的 [CALL指令（http://www.penguin.cz/~literakl/intel/c.html#CALL）…你一定得探索物件，甚至可能要扫瞄一个杂凑表才能找到所要呼叫的函数。呼叫物件的方法是个极为常用的操作，在纯物件导向的语言中更是如此。有些语言的物件型别可以在编译时期决定，所以跳跃的指令可以在编译时得到（如ç语言），或是透过单一个虚函数表用一个间接指令取得（如C ++中）.Ruby至少得把那一小段程式码，化简成一个间接CALL的CPU指令，才能提供和这类语言相当的效能。

我了解开发时间比CPU时间更重要的原理，不过坦白说那只不过是保险杆贴纸上的口号，对抱怨效能的人来说并不公平。敝公司的产品的FogBugz似乎应该很适合用红宝石 on Rails开发，不过其中还是有些地方的效能极为重要.FogBugz 6里就有个地方，得进行数百万次运算才能在单一个网页上显示一个图表。我们在目前的开发环境下做了许多最佳化，才把运算时间缩到三秒左右。坦白地说，如果是用duck- 输入函数呼叫的话，我不认为我们能在网页浏览器逾时前或在合理时间内完成。我们也必须用贝叶斯过滤器扫瞄进入的电邮讯息。这个计算密集的操作过滤一个讯息约要一秒。对我们很多客户而言，每秒收到一封电子邮件并不算离谱，所以现在的效能非常接近CPU运算能力的极限。而这已经是用一种执行这类程式码比红宝石快数个量级的语言了。改用红宝石的话我们稳死无疑。

就算是典型单纯的CRUD应用程式，也就是那种只是由资料库读个资料表显示出来，让你增删编辑各笔资料的应用程式，在深入到程式码某处时，都常会发现某些需要密集运算的动作。比如网志软体可能会要用贝叶斯过滤器来消除垃圾意见。你在这种地方就会突然明白，你所选的语言比竞争者慢上十倍，于是你根本就无法加上该功能，不然就得呼叫另一种语言（并且承受附带的转换整编（编组）负担）。

并不是每个人都会遇到这种问题，不过当人们说遇到的Ruby的效能问题，或仅仅只是想让程式执行得比核心的红宝石语言引擎更快时，红宝石拥护者唱歌颂赞「开发者时间与CPU时间」是没有用的。就算你不做需要密集运算的东西，如果发现自己得买100台伺服器而非10台时，你可能就会突然重新思考整个开发者时间与CPU时间的方程式。

我了解有些计画要用某种字节码编译器来处理的Ruby的效能问题，这很不错。当这些计画实现而且红宝石也出现具竞争力的效能评比后，对各式各样的应用可能会更为适合。不过在那之前，我还是会声称并非每种状况都适合使用红宝石。

**关于作者：**我是本站站长Joel Spolsky的，是一位纽约市的软体开发者。我从2000年起在本站撰写与软体开发，管理，商业以及互联网相关的文章。我平日的工作是经营[雾 溪 软件]（http://www.fogcreek.com）这家公司，产品包括[FogBugz的]（http://www.fogcreek.com/FogBugz）这个有个蠢名字但聪明的问题追踪软体，还有透过互联网最简易的远端技术支援方案[雾 Creek Copilot]（https://www.copilot.com），完全不用安装或设定。