代码大全 25章

本章讨论程序性能调整问题——这一直以来都是一个富有争议的话题。在20世纪60 年代，计算机资源非常有限，因此效率成了人们极为关注的一个问题。到了70年代，随着计算机的功能越来越强大，程序员们意识到过分专注于性能会损害程序的可读性和可维护性，因而代码调整受到的重视程度有所下降。性能限制随着80年代微型计算机革命的开始而重新提了出来，效率问题又被推到台前，在整个90年代中它被人关注的程度则逐渐下降。21世纪初，移动电话和PDA等设备上嵌八式软件受到的内存限制，以及解释型代码的执行时间过长，使效率再度成为了一个热点话题。 你可以在两个层面上考虑性能问题： 策略上和技术上。

相对于代码质量(quality)，用户更关心的是程序的外在特性。有时，人们也会在乎纯粹的性能，但这仅仅是在性能影响到了用户工作的时候。相互肝 纯粹的性能，用户更为重视的是程序的处理能力(throughput，吞吐量)。对用户 来说，程序员按时交付软件，提供一个清爽的用户界面，避免系统死机常常比程序的性能更为重要。

如果你的程序要同外部文件、动态内存或输出设备打交道，那么程序很可能需要同操作系统进行交互。如果程序性能不尽人意，很可能是操作系统的子程序 (例程) 过于低效或臃肿。你或许没有注意到你的程序正向操作系统进行交互， 因为有时你的编译器会生成系统调用，或是程序库使用了你未曾想到的系统调用。

代码调整出于以下几个原因而受到了程序炅们的青踩。这种方法似乎是在藐视自然法则。调整几行代码，就能把原本运行起来会花上20微妙的程咩优化到运 行时间只有2微秒，这给程序员们带来了不可思议的成就感。

Bwy Boehm 的研究表明，程序中20%的子程序耗费了80%的执行时间 (1987b)。在Donald Knuth的经典论文"An Empirical Study of Fortran Programs" 中，作者发现程序中不足4%的部分常常占用了超过50%的运行时间(1971) . Knuth通过一个代码行剖测器发现了这一惊人的关系，这一结论对优化工作的影响显而易见。程序员们应当衡量代码的各个部分，找出最需要关注的地方，然后集中火力来对付占用了绝大部分资源的少量代码。Knuth 对自己的代码行剖测器进 行了性能分析，发现其中两个循环占用了整个程序-半的执行时间。于是他花不到 一个小时对这部分代码中的几行进行了修改，整个程序的速度就翻了一倍。

Jon Bentley也提到了一个案例，在一个拥有1000行代码的程序中，80%的运行时间都花费在了一个只有5行的平方根计算子程序中。把这一子程序的运算 速没提高三倍之后，整个程序的运行速度也提高了一倍。根据Pareto法则，当某个程序绝大多教的代码都是由诸如即python这样的解释型语言编写时，程序员同样应该把其中最关键的部分用C这样的编译型语言重写。

曾设计了ALGOL语言的团队(Algol是绝大部分现代语言的开山鼻祖，也是有史以来最具影响力的语言之一) 得到了下面的建议：‘The bost the emmy of the good.”(完美是优良之大敌)。愈是追求完美，越有可能完不成任务。程序员们首先应该实现程序应该具备的所有功能，然后再使程序臻于完美。而这时，需要精益求精的部分通常是很少的。

程序运行速度同其正确性同等重要下——错误！在程序无法正确运行的时候，不可能去要求程序应当更小巧或是运行得更快！

程序员应当使用高质量的设计，把程序编写正确。使之模块化并易于修改， 将让后期的维护工作变得很容易。在程序已经完成并正确之后，再去检查系统的性能。如果程序运行迟钝，那么再设法让它更快更小。除非你对需要完成的工作 清二楚，否则绝不要对程序做优化。

应当随时随地进行优化——错误
一种理论认为，如果你努力使每一个子程序达到最快和最小，那么你的程序也一定会非常小并且运行得很快。这样的方法会让程序员们陷入一叶障目的境地，程序员为微观范围的优化忙得不可开交，而对整个系统全局性的重要优化视而不见。

在高级语言中，减少代码的行数就可以提升所生成的机器代码的运行速度，或是减少其资源占用——错误！很多的程序员都顽固不化地坚持这样的信念：如果他们能写出只有一两行代码的程序，那么这个程序将会最大限度的高效。

Pareto法则也就是众所周知的80/20法则。它讲述的是你可以用20%的努力取得80%的成效。这一法则适用于程序设计之外的众多领域，它对程序优化也绝对有效。