前言

大致看了一下这本书，主要介绍了性能测量方式以及性能调优方法，对于软件工程师而言，确实有很大的帮助，可以提前知道如何编写提升CPU执行性能的代码，减少后续优化的麻烦。

本周主要阅读了本书的第一章节“性能测量”，本文是对该章节读书笔记。

性能测量

噪声

本章节首先介绍了现在系统的噪声，说明了对性能测量是及其难以测准的，因为会有各种影响因素：

• 动态频率调节（DFS，硬件特性，我也是第一次听说这个名词），主要意思是现在的CPU的频率是会动态变化的，针对同一个软件，当CPU长时间处于空闲状态（CPU温度较低）时测量和一直处于busy状态（CPU温度较高）测量，其CPU工作频率是不一样的，当CPU温度较低的时候测量是CPU会超频，测试结果会好于CPU温度较高时的测量结果。
• 软件功能差异，对于文件系统而言，第一次运行和第二次运行差异也很大，因为第一次运行，会缓存一些数据项，消耗一些时间，第二次运行则不会。
• UNIX系统的环境变量的长度也会影响性能。
• 内存排布。

本章节还说了在大型系统中确保一个软件在每次测量时的环境都一样，基本上是不可能。所以对性能的测量也应该在最接近真实使用环境情况下进行测量。

如下图，第一次运行的时候CPU超频，统计时间会小于第二次运行。

生产环境中的性能测量

在生产环境中，噪声是永远存在的，现在一些共享基础设施运行在云端，可能会有来自其他客户的计算负载的存在，对性能的影响是不可避免的。所以测试的时候应该在用户真实使用场景中测试，接收存在噪声的天然属性，使用统计的方式进行分析。

自动检测戏能退化问题

在该章节中说明了随着软件的版本更替，软件的性能下降几乎是不可避免的，因为大型软件在持续集成和部署是都会出现性能退化的问题。通过测试工具以及诊断工具可以将缺陷渗透到生产代码的可能性降到最低。

该章节描写了一种性能识别方法：

• 改动点分析，MongoDB的开发者使用这种方法。
• AutoPerf，利用硬件性能计数器来诊断修改后的程序是否发生了性能退化。

无论使用哪种方法，CI（持续集成）系统都应该自动进行以下动作：

1. 配置待测试系统
2. 运行程序
3. 报告运行结果
4. 判断性能是否发生变化
5. 将结果可视化展示

手动性能测试

当需要提交新的代码的时候，需要进行性能测：

1. 测试基线性能
2. 测试修改后的程序性能
3. 对两种进行比较

但是不能只进行一次测试，而应该运行多次，进行统计比较，画出分布图。

软件计时器和硬件计时器

对执行时间做基准测试，一般使用如下两种计时器：

• 系统级高分辨率计时器（纳秒级，通常用来测量持续时间超过1us的事件）
• 时间戳计时器（TSC，适合测量纳秒到1min之间的时间）

所以，对于测量时间很短的软件，选择TSC，对弈测量时间很长（几小时）选择系统计时器。

总结

我对不对这张做总结了，作者总结的就已经很好了。

后记

这本书对软件工程师而言，尤其是大型持续集成软件的软件工程师有很大的指导意义，可以帮助分析软件的戏能。本书介绍的一些测试方法都对工作有指导作用。后续章节更是详细的描述了一些测试方法，值得学习。我也会再后边慢慢将本书读完，学习测试方式，应用在工作中，谁能拒绝写性能强悍的软件呢。