From The Joel on Software Translation Project

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

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

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

David Heinemeier Hansson写著：

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

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

我看过许多拿Java(对我而言不算快)之类的bytecode语言和Ruby效能对照的比较，而且我也看到很多效能报告声称Ruby慢十倍或慢五十倍云云。除了少数的网志鬼扯外，Ruby在电脑语言对抗评比上几乎是稳吊车尾了。

我并不知道Ruby实现的细节，不过我猜最大的问题大概是在晚期连结(late binding)以及最主要的鸭子类型处理(duck typing)吧，有了后者就不能用类型参考或是强类型处理。这表示函数的呼叫一定会慢，因为你永远没有办法把函数呼叫编译成单一个x86指令集的

CALL指令...你一定得探索对象，甚至可能要扫瞄一个杂凑表才能找到所要呼叫的函数。呼叫对象的方法是个极为常用的操作，在纯面向对象的语言中更是如此。有些语言的对象类型可以在编译时期决定，所以跳跃的指令可以在编译时得到(如C语言)，或是透过单一个vtable用一个间接指令取得(如C++中)。Ruby至少得把那一小段程序代码，化简成一个间接CALL的CPU指令，才能提供和这类语言相当的效能。

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

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

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

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

关于作者： 我是本站站长Joel Spolsky，是一位纽约市的软件开发者。我从2000年起在本站撰写与软件开发、管理、商业以及Internet相关的文章。我平日的工作是经营Fog Creek Software这家公司，产品包括FogBugz这个有个蠢名字但聪明的问题追踪软件，还有透过Internet最简易的远端技术支持方案Fog
Creek Copilot，完全不用安装或设定。