分析（可能受 I/O 限制）进程以减少延迟

我想提高大型应用程序中特定方法的性能。

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

要求：

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

迄今为止废弃的工具：

• gprof、oprofile、callgrind（要求 1）
• 使用 getrusage 构建自定义内容（要求 1）
• badmansprofiler.org（要求 2）
• strace -T，dtrace，http://perf.wiki.kernel.org http://perf.wiki.kernel.org（要求2和3）
• VTune、缩放（要求 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/ http://balau82.wordpress.com/2010/10/06/trace-and-profile-function-calls-with-gcc/

这个原始工具产生的跟踪很难解释，我可以很容易地想象一些工具可以进一步处理其输出，使其变得更加有用。然而，这对我来说目前已经完成了工作，所以我将该项目推迟到以后;)。

Use 这个方法 https://stackoverflow.com/a/378024/23771.

无论是在 CPU 还是 IO 密集型代码中，它都非常简单且有效地找出优化机会。

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

在您提到和放弃的工具中，它与穷人的分析器最相似，但仍然不是很相似。

编辑：既然您说它是由用户交互触发的，并阻止进一步的输入直到完成，那么我将这样做。

首先，我假设它不会阻止向调试器发送手动中断信号，因为否则您将无法停止无限循环。 其次，我会围绕相关例程循环 10、100 或 1000 次，因此它的执行时间足够长，可以手动中断。

现在，假设它花费一小部分时间进行 I/O，例如 50%。那么当你中断它时，你有 50% 的机会在 I/O 中捕获它。 因此，如果您在 I/O 中捕获它（调用堆栈会告诉您），您还可以详细了解从何处请求 I/O 以及原因。

它会向您展示正在发生的事情，这几乎肯定是令人惊讶的事情。 如果您看到它在少至两 (2) 个样本上执行某些操作，并且您可以找到消除的方法，那么您将获得相当大的加速。 事实上，如果您消除该活动，您事先并不知道您将节省多少时间，但平均而言您可以预期节省一小部分时间F = (s+1)/(n+2), where n是您采集的样本总数，并且s是显示活动的样本数。(继承规则) http://en.wikipedia.org/wiki/Rule_of_succession例如，如果您采集了 4 个堆栈样本并查看了其中 2 个的活动，那么平均而言，这会节省您的时间F = 3/6 = 1/2，对应于加速因子1/(1-F) or 2.

完成此操作后，您可以再次执行此操作并找到其他问题来修复。 加速因素像复利一样相乘。

然后，当然，您删除了外循环并“兑现”了您获得的所有加速。

如果您想知道这与分析有何不同，那就是通过仔细检查每个堆栈样本以及可能相关的数据，您可以识别可以删除的活动，如果您拥有的只是测量值，那么您只能尝试凭直觉来了解到底是怎么回事。 无论进行何种测量，您实际节省的时间就是实际节省的时间。 重要的是find问题。 无论分析器测量得多么精确，如果你不能find它，你没有赢。 这些页面上充满了人们说他们要么不明白他们的分析器告诉他们什么，要么似乎在说没有什么可以修复的，而他们非常愿意接受。 这是一个有色眼镜的情况。

更多关于这一切。 https://scicomp.stackexchange.com/a/2719/1262