Question

众所周知，好的编程语言生成的代码有较快的运行速度。但是实际上，我觉得代码的运行速度不是编程语言的设计者能够控制的。高德纳很久以前就指出，运行速度只取决于一些关键的瓶颈。而在编程实践中，许多程序员都已经注意到自己很容易搞错瓶颈到底在哪里。

所以，编程时提高代码运行速度的关键是使用好的性能分析器（profiler），而不是使用其他方法，比如精心选择一种静态类型的编程语言。为了提高运行速度，并没有必要每个函数的每个参数类型都声明清楚，你只需要在瓶颈处声明清楚参数类型就可以了。所以，更重要的是你需要能够找出瓶颈到底在什么地方。

人们在使用非常高级的语言（比如Lisp）时，经常抱怨很难知道哪个部分对性能的影响比较大。可能确实如此，如果你使用一种非常抽象的语言，这也许是无法避免的。不管怎样，我认为一个好的性能分析器会解决这个问题，虽然这方面还有很长的路要走，但是未来你可以快速知道程序每个部分的时间开销。

这个问题一部分源于沟通不畅。语言设计者喜欢提高编译器的速度，认为这是对自己技术水平的考验，而最多只把性能分析器当作一个附送给使用者的赠品。但是在现实中，一个好的性能分析器对程序的帮助可能大于编译器的作用。这里又一次反映出语言设计者与用户之间发生了脱节，前者竭尽全力想要解决的问题其实方向不甚正确。

让性能分析器自动运行可能是一个好主意。它自动告诉程序员每个部分的性能，而不是非要等到程序员手动运行后才能知道。比如，当程序员编辑源码的时候，代码编辑器能够实时用红色显示瓶颈的部分。另一个方法应该是设法显示正在运行的程序的情况，这对互联网软件尤其重要，因为服务器上有很多程序同时运行，它们都需要你密切关注。自动运行的性能分析器用图形实时显示程序运行时的内存状况，甚至可以发出声音，表示出现了问题。

出现问题时，声音是很好的提示。我们在Viaweb搞了一块很大的面板，上面有各种各样的仪表盘，用来显示服务器的状况。仪表盘的指针由微型马达驱动，每当马达旋转的时候，就会发出一阵轻微的噪音。在我的工位没法看到仪表盘，但是只要我听到声音，就能立刻知道服务器出现了问题。

性能分析器甚至有可能自动找出不合理的算法。如果将来有人发现某种形式的内存访问是不合理算法的信号，我不会感到很惊讶。如果有一个小人儿可以钻进计算机看看我们的程序是怎么运行的，他可能会变成一个忙碌又悲惨的可怜虫，就像那些为政府跑腿的小人物。我总觉得自己用处理器做了很多无用功，伹是一直没有找到能够看出程序是怎样浪费运算能力的好办法。

现在有一些语言先编译成字节码（byte code），然后再由解释器执行。这样做主要是为了让代码容易移植到不同的操作系统，伹是这也可以变成一项很有用的功能。让字节码成为语言的正式组成部分，允许程序员在瓶颈处内嵌字节码，这可能是一个不错的主意。然后，针对这部分字节码的优化也就变得可以移植了。

正如许多最终用户已经意识到的，运行速度的概念正在发生变化。随着互联网软件的兴起，越来越多的程序主要不是受限于计算机的运算速度，而是受限于I/O的速度。加快I/O速度将是很值得做的一件事。在这方面，编程语言也能起到作用，有些措施是显而易见的，比如采用简洁、快速、格式化输出的函数，还有些措施则需要深层次的结构变化，比如采用缓存和持久化对象（persistent object）。

用户关心的是反应时间（response time），但是软件的另一种效率正在变得越来越重要，那就是每个处理器能够同时支持的用户数量。未来许多有趣的应用程序都将是运行在服务器端的互联网软件，所以每台服务器能够支持的用户数量就成了软件业者的关键问题。互联网软件的资本支出就取决于这个指标。

许多年以来，大多数面向最终用户的程序都不太关心效率。软件开发者总是假设用户桌面电脑的运算能力会不断增长，所以不用刻意提高软件的效率。帕金森定律^被证明与摩尔定律一样颠扑不破。软件不断膨胀，消耗光所有可以得到的资源。这一切将随着互联网软件的出现发生改变，因为硬件和软件现在捆绑在一起供应。对于那些提供互联网软件的公司来说，每台服务器支持的用户数量最大化会对降低成本产生巨大影响。

^「帕金森定律（Parkinson's Law）的一种原始表达形式是“工作总是到最后一刻才会完成”，后来引申到计算机领域就变成了“数据总是会填满所有空间”，更一般性的总结则是“对一种资源的需求总是会消耗光这种资源的所有供应”。——译者注」

在一些应用程序中，处理器的运算能力是瓶颈，那么最重要的优化对象就是软件的运行速度。但是，一般情况下内存才是瓶颈，你能够同时支持的用户数量取决于用户数据所消耗的内存。编程语言在这方面也能发挥作用，对线程的良好支持将使得所有用户共享同一个内存堆（heap）。持久化对象和语言内核级别的延迟加载（lazy loading）支持也有助于减少内存需求。