文章目录
性能优化前思考
性能与可读性/可维护性之间的权衡
程序的性能调整一直以来都是的一个有争议的话题。60年代计算机资源非常有限 对性能极其关注。到70年代，计算机功能越来越强大，过分关注性能会损害程序的可读性 可维护性，重视程度有所下降。随着80年代 微型计算机出现，和 21实际初 嵌入式设备 诞生的节点，又在一定时间段成为热点。
性能与用户的关联，存粹的性能价值如何
用户更关心的是程序外在特性，只有当性能影响到用户工作时，人们才会关注性能特性（关键质量特性需求）。绝大部分情况 相对存粹的性能，用户更重视的是程序的吞吐量；
性能是执行整体表现，性能优化一定要多维度分析
性能优化一定是多维度分析的，针对热点改进的。没有策略的盲目优化不如不优化。
不要随时随地的调整代码，缺乏前瞻性，陷入细节，抓不住瓶颈
对性能优化工作最好的准备方式就是在最初阶段编写清晰的代码，让代码在后续工作中更易于理解和修改。
如果你努力使每一个子程序最快最小，你的程序一定非常小并且运行快么？这种方法不但会让程序员陷入盲目的细节优化调整，并且容易一叶障目对系统全局优化视而不见。并且有以下几个问题：
1、几乎不可能在程序所有功能都运转之前确定程序性能瓶颈。
2、在极少情况下，程序员能正确的确定程序真正瓶颈，但他们可能陷入一部分代码痛下重手。
3、在初期开发阶段，过多的集中在性能优化会干扰对给用户真正有价值的特性理解和判断。你在后期愿意投入去处理5%代码的效能，还是去改善100%代码的可读性？
Pareto法则—20%努力获得80%成效，热点效应
对于大部分程序，20%的子程序耗费了80%的执行时间，进一步不足4%的部分常常占用了超过50%运行时间。换句话将，我们一定是针对热点进行优化，不要盲目的全面改动。
优化一定基于测试数据，避免主观的推测计算性能
没有实际的测量，你通常无法知道哪些操作会更费时，性能测量一定要精确，注意测试的一定是分配给CPU时钟来计算，不要把调度到其他执行流的时间片也算到测试数据中。
当然某些特定的操作通常都会有相对固定的效率，可以做参考，常见如下：
一旦抓到性能瓶颈，就要反复调整优化
代码性能优化提升是持续累计得来的，绝大部分优化方法看起来可能收效甚微，但是累计起来能得到惊人的效果。
《代码大全》作者在书中针对热点瓶颈反复编码优化的过程如下：
性能优化的维度
需求分析，是否真的是一个性能问题？
审视性能质量特性需求，是否是一个真实需求？需求背后真实原因？成本影响？有无其他策略；
举例：客户希望这个请求必须1S内完成原因是什么？什么场景下需要有这么高的标准，90%场景下4S能满足客户的要求么？降低到1S要涉及多高成本增加？真的必须到1S才能满足客户真实诉求吗，有没有其他方案？
顶层框架交互设计，是否易于高性能实现？
在最顶层的设计中，约束了基本的数据流、控制流。决定了基础数据交互数量级和方式。
如果对程序关键规格的 资源占用和速度有要求，就应该在框架设计的层级满足这些要求；然后再在子系统、子模块级别达到其分解的目标。
子系统数据类型和算法设计，是否高效？
有了良好的顶层设计基础。当目标划分到子系统级别，这个层次需要选用合适的数据结构和算法类型，这两者将会同时影响程序的内存占用和执行速度。如用快排序替代冒泡，用折半查找替代线性查找。
子系统与操作系统交互，是否低效或臃肿？
当你的程序需要和 外部文件读写 / 动态内存申请释放 / 数据IO设备访问 频繁打交道时。要注意审视这些交互行为 是否过于低效和臃肿；很多时候系统交互频繁 是 影响性能的一大问题。
文件访问最小化，或使用缓存降低读写频次；构造内部内存池，管理小内存申请释放；优化不必要的io数据访问 等 方法都能有效提升这些地方的性能；
编译器和编译选项，是否选择合理？
相对手动代码调整，针对编译器的优化效率更高，你可能根本不需要修改任何代码执行效率就达到了设计目标，并且更安全。有强有力的编译器，通常可以提高40%甚至以上的速度提升。但是要注意一点：
编译器优化功能对那些平铺直叙的代码更有效，避免在编码里面加入一些想当然的”花招“，这反而会影响编译器优化。
硬件瓶颈，当前项目是否可以部分升级？
有时候，最经济最有效的办法就是购买新的硬件设备。特别是针对个别内部客户开发定制软件，或许硬件设计是更好的办法，节省了性能优化的工作初期投资，和将来性能问题投入成本。整体上改善硬件设备上运行的全部程序的性能；
语言层级优化，单个类/子模块/函数级别的代码调整
语言层级的代码优化，针对某个类，某个函数 甚至就是几行代码的优化。
相对设计改善，算法改善 它可能带来的收益没有那么高，提升的效率往往是最低的。
同时他的成本却不低，在初期阶段耗费在手工调整代码时间越多，后期就可能越难维护（很多语言层级的代码优化都会影响到可读性和可维护性）
他的价值在于：掌握编写高效代码这门技术是成为优秀程序员必经之路，但是要注意 高效的代码 并不一定是更好的代码，需要权衡。
常见性能检查工具（待总结）
参考资料
《代码大全》