C++ 性能优化篇一《优化概述》

1.1　优化是软件开发的一部分

优化是一项编码活动。在传统的软件开发过程中，直到编码完成，项目进入了集成与测试 阶段，能够观察到程序整体的性能时，才会进行优化。而在敏捷开发方式中，当一个带有 性能指标的特性编码完成后或是需要实现特定的性能目标时，就会分配一个或多个冲刺 （sprint）进行优化。 性能优化的目的是通过改善正确程序的行为使其满足客户对处理速度、吞吐量、内存占用 以及能耗等各种指标的需求。因此，性能优化与编码对开发过程而言有着同等的重要性。 对于用户而言，性能糟糕得让人无法接受，这个问题的严重程度不亚于出现 bug 和未实现 的特性。 bug 修复与性能优化之间的一个重要区别是，性能是一个连续变量。特性要么是实现了， 要么是没有实现；bug 要么存在，要么不存在。但是性能可以是非常糟糕或者非常优秀， 还可能是介于这二者之间的某种程度。优化还是一个迭代的过程。每当程序中最慢的部分 被改善后，一个新的最慢的部分就会出现。 与其他编码任务相比，优化更像是一门实验科学，需要有更深入的科学思维方式。要想优 化成功，需要先观察程序行为，然后基于这些程序行为作出可测试的推测，再进行实验得 出测试结果。这些测试结果要么验证推测，要么推翻推测。经验丰富的开发人员常常相信 他们对于最优代码具有足够的经验和直觉。但是除非他们频繁地测试自己的直觉，否则通 优化概述 ｜ 3 常他们都是错误的。在我个人为本书编写测试代码的经历中，就多次出现测试结果与我的 直觉相悖的情况。实验，而非直觉，才是贯穿本书的主题。

1.2　优化是高效的

开发人员很难理解单个编码决策对大型程序的整体性能的影响。因此，实际上所有完整的 程序都包含大量的优化机会。即使是经验丰富的团队在时间充裕的情况下编写出的代码， 运行速度通常也可以提高 30% 至 100%。我见过对在时间很紧张的情况下或是欠缺经验的 团队编写出的代码进行优化后，程序运行速度提高了 3 至 10 倍的情况。不过，通过微调 代码让程序的运行速度提升 10 多倍几乎是不可能的。但是选择一种更好的算法或是数据 结构，则可以将程序的某个特性的性能从慢到无法忍受提升至可发布的状态。

1.3　优化是没有问题的

许多关于性能优化的讨论都会首先严正地警告大家：“不要！不要优化！如果确实需要， 那么请在项目结束时再优化，而且不要做任何非必需的优化。”

例如，著名的计算机科学 家高德纳曾经这样说过：

我们应当忘记小的性能改善，百分之九十七的情况下，过早优化都是万恶之源。 ——高德纳 2 ，Structured Programming with go to Statements，ACM Computing Surveys3 6(4), December 1974, p268. CiteSeerX4 : 10.1.1.103.6084 （http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.6084）

威廉 • 沃尔夫 5 曾说过：

以（没有必要达成的）效率之名犯下的计算之罪比其他任何一个原因（包括盲目 愚蠢）都多。 ——A Case Against the GOTO，第 25 届美国 ACM 会议论文集（1972）： 796

“不要进行优化”

这条建议已经成为了一项编程常识，甚至许多经验丰富的程序员都认为 这是毋庸置疑的。他们对性能调优避而不谈。我认为过度推崇这条建议经常被用作两种行 为的借口：编程恶习，以及逃避做少量分析以让代码运行得更快。同时我还认为，盲目地 接受这条建议会导致浪费大量 CPU 周期、用户满意度下降，会浪费大量时间重写那些本 应从一开始就更加高效的代码。

我的建议是不要过于教条。优化是没有问题的。学习高效的编程惯用法并在程序中实践之 是没有问题的，即使你不知道哪部分代码的性能很重要。这些惯用法对 C++ 程序很有帮 助。使用这些技巧也不会让你被同事鄙夷。如果有人问你为什么不写一些“简单”和低效 的代码，你可以这么回答他：“编写高效代码与编写低效无用的代码所需的时间是一样的， 为什么还会有人特意去编写低效的代码呢？”

但是，如果你不清楚重要性，因为不确定哪个算法更好而导致许多天过去了项目仍毫无进 展，这是不行的。你因为猜测某段代码有严格的执行时间的要求，就花费数周时间去编写 汇编