1、terms16、谨记80-20法则
二八法则适用于世界上绝大多数情况，世界的财富有20%的人创造的，公司的收益是由20%的员工创造出来的，等等等等。软件资源同样也遵循这个规律。
一个程序 80% 的资源用于20% 的代码身上。
这里的资源包括：执行时间、内存消耗、磁盘访问、维护成本…
这说明了：软件的整体性能几乎总是由其构成要素（代码）的一小部分决定。也给我们指明了提升软件性能的一个方向：我们只要找到这20%的代码，并进行相应的优化，那么我们程序的运行速度就可以有较大的提高。
而怎样找到这20%的代码，有两种不同的方法：
（1） 根据程序员的直觉和经验“猜”出影响软件性能提高的瓶颈代码。
但往往大部分程序员对于程序的性能特质，都有错误的直觉，因为程序的性能特质倾向高度的非直觉性。
举个例子，我们当然可以采用某些特选的算法和数据结构加入程序之中，将运算量最小化，但如果这个程序受制于 I/O（所谓 I/O-bound），那么前述种种努力对性能就一点帮助也没有。我们可以选用威力强化的 I/O 程序库来取代编译器所附的版本，但如果程序受制于 CPU（所谓 CPU-bound），这对性能也发挥不了什么作用。
（2）借助某个程序分析器识别出造成你心痛的那 20% 代码。
程序分析器（program profiler），它实际上是一些公司所开发的工具，可以检查程序中各个模块所分配内存的使用情况，以及每个函数所运行的时间等。常见的Profiler有Intel公司开发的VTune，微软公司开发的Visual Studio profiler，DevPartner from Compuware等。
当然，即使是最好的分析器（profilers）也受制于它所使用的数据。如果你以无法重现的（unrepresentative）数据去分析你的程序，然后分析其行为，那么万一分析器引导你去调整属于 80% 那一部分代码，它们对于整体性能通常没有任何的改善。
所以记住，分析器只能告诉你程序在某次（或某组）特定执行过程中的行为，因此如果你以无法重现的数据分析你的程序，你便是在分析无法重现的行为。那可能会导致你对一些不常被使用的程序行为做优化努力，这对常用部分的整体冲击可能反而是负面的。
防范这种病态结果的最佳办法就是尽可能地以最多的数据来分析你的软件。
2、总结
书山有路勤为径，学海无涯苦作舟。
3、参考
3.1《More Effective C++》