分析（可能是I / O绑定）进程以减少延迟

Question

我想在更大的应用程序中改进特定方法的性能。

目标是改善延迟（在特定功能中花费的挂钟时间），而不是（必要的）系统负载。

要求：

1. 由于I / O会导致很多延迟，因此请考虑等待/阻止所花费的时间（换句话说：查看挂钟时间而不是CPU时间）
2. 由于程序的功能远远超过我想要优化的片段。需要有一种方法可以以编程方式启动/停止分析，或者过滤输出以仅显示进入和退出我正在优化的功能之间的时间。
3. 方法级别的分析是可以接受的（如果它可以在指令级别完成，甚至更好。如果它只是配置系统调用，那可能还不够）
4. 这是一个爱好项目，所以昂贵的工具不是一个真正的选择
5. 仪器（-finstrument-functions）是可以接受的
6. 我感兴趣的关键代码很难手动中断（因为它已经相对快速且难以在循环中实际调用），因此需要进行某种自动化。

到目前为止丢弃的工具：

• gprof，oprofile，callgrind（要求1）
• 使用getrusage（要求1）建立自定义内容
• poormansprofiler.org（要求2）
• strace -T，dtrace，http://perf.wiki.kernel.org（要求2和3）
• VTune，Zoom（要求4）
• 手动调用堆栈采样（要求6）
• google-perftools（应该可以测量墙上时间，但这似乎不适用于我的情况，大概是因为SIGALRM干扰。
• systemtap（我的内核未修补包含utrace）

我尚未进一步评估的其他选项：

• cprof（这里没有开箱即用，似乎只支持i386）
• 手动插入跟踪点（例如，使用lttng）

我很想听听：

• 其他选项
• 也许我太早丢弃了一些工具？
• 我尚未评估的选项是否有可能发挥作用，如果是，最好如何做到。

我终于安顿下来了：

• 使用-finstrument-functions构建自定义内容，基于http://balau82.wordpress.com/2010/10/06/trace-and-profile-function-calls-with-gcc/

这个粗略工具产生的痕迹很难解释，我可以很容易地想象一些工具来进一步处理它的输出，使它变得更加有用。但是，这对我来说现在已经完成了这项工作，所以我把这个项目推迟到以后;）。

Answer 1

使用this method。

在精确定位优化机会方面非常简单有效，无论是在CPU还是IO绑定代码中。

如果你认为特定功能或模块中最大的机会是正确的，那么它就会找到它们。如果他们在其他地方，它会找到它们。

在你提到和丢弃的工具中，它与穷人的探查器最相似，但仍然不太相似。

编辑：因为你说它是由用户交互触发并阻止进一步输入直到完成，所以我就是这样做的。

首先，我假设它不会阻止调试器的手动中断信号，因为否则你无法阻止无限循环。 其次，我会围绕有问题的例程循环一次10,100或1000次循环，所以它做得足够长，可以手动中断。

现在，假设它花了一些时间做I / O，比如50％。然后当你打断它时，你有50％的机会在I / O中捕获它。 因此，如果您在调用堆栈将告诉您的I / O中捕获它，您还可以非常详细地查看请求I / O的位置以及原因。

它会告诉你发生了什么，这几乎肯定是令人惊讶的。 如果你看到它只用两（2）个样本就可以找到一种消除方法，那么你将获得相当大的加速。 事实上，如果你消除了这种活动，你事先并不知道你会节省多少时间，但平均而言你可以节省分数 F =（s + 1）/（n + 2），其中 n 是您拍摄的样本总数， s 是显示活动的样本数。 (Rule of Succession) 例如，如果您采用了4个堆栈样本并在其中2个上看到了活动，则平均会节省 F = 3/6 = 1/2 ，对应于 1的加速因子/（1-F）或2.

完成后，您可以再次执行此操作并找到其他要修复的内容。 加速因子像复利一样倍增。

然后你当然会移除外圈并“兑现”所有加速。

如果您想知道这与分析的不同之处在于，通过仔细检查每个堆栈样本和可能的相关数据，您可以识别可以删除的活动，如果您只有测量结果，那么您就会离开试图直觉发生了什么事。 无论测量结果如何，您保存的实际时间都是实际的。 重要的是找到问题。 无论分析器如何精确地测量它，如果你不能找到它，你就不会获胜。 这些页面上到处都是人们说他们不明白他们的探查者告诉他们的是什么，或者似乎在说没有什么可以解决的，他们只是太愿意接受。 那是一款玫瑰色眼镜。

More on all that.

Answer 2

对于I / O绑定的应用程序，您可以使用callgrind的--collect-systime=yes选项。

这会收集系统调用所花费的时间（以毫秒为单位）。 因此，如果您认为自己有I / O瓶颈，则可以使用这些统计信息来识别它。

Answer 3

Todo：查看'perf'（再次）

Answer 4

• fork（）的
• execxxx（正在测试的过程）
父母中的
• ：
  • （循环中）定期致电：
  • getrusage（RUSAGE_CHILDREN，...）

getrusage（）不仅会为您提供cpu使用，还会提供主要/次要页面故障，上下文切换次数等。剩下的时间可能花在等待I / O上。这不会为您提供详细的性能分析信息，但是对于程序行为的总体占用空间很小，与每个进程运行vmstat相当。