Arn*_*len 10 linux performance trace profiling sampling
我想在更大的应用程序中改进特定方法的性能.
目标是改善延迟(在特定功能中花费的挂钟时间),而不是(必要的)系统负载.
要求:
迄今为止丢弃的工具:
我尚未进一步评估的其他选项:
我很想知道:
我终于安顿下来了:
这个粗糙工具产生的痕迹很难解释,我可以很容易地想象一些工具来进一步处理它的输出,使它更加有用.但是,这对我来说现在已经完成了这项工作,所以我把这个项目放到了以后;).
使用这个方法。
无论是在 CPU 还是 IO 密集型代码中，它在查明优化机会方面都非常简单且有效。
如果你认为最大的机会是在某个特定的功能或模块中，那么它就会找到它们。如果他们在其他地方，它会找到他们。
在您提到和放弃的工具中，它与穷人的分析器最相似，但仍然不是很相似。
编辑：既然您说它是由用户交互触发的，并阻止进一步的输入直到完成，那么我将这样做。
首先，我假设它不会阻止向调试器发送手动中断信号，因为否则您将无法停止无限循环。其次，我会围绕相关例程循环 10、100 或 1000 次，因此它的执行时间足够长，可以手动中断。
现在，假设它花费一小部分时间进行 I/O，例如 50%。那么当你中断它时，你有 50% 的机会在 I/O 中捕获它。因此，如果您在 I/O 中捕获它（调用堆栈会告诉您），您还可以详细了解从何处请求 I/O 以及原因。
它会向您展示正在发生的事情，这几乎肯定是令人惊讶的事情。如果您看到它在少至两 (2) 个样本上执行某些操作，并且您可以找到消除的方法，那么您将获得相当大的加速。事实上，如果消除该活动，您事先并不知道会节省多少时间，但平均而言，您可以节省分数F = (s+1)/(n+2)，其中n是您采集的样本总数，s是显示活动的样本数。 （继承规则） 例如，如果您获取 4 个堆栈样本并查看其中 2 个的活动，平均而言，它将为您节省F = 3/6 = 1/2，对应于加速因子1/(1-F )或 2。
完成此操作后，您可以再次执行此操作并找到其他问题来修复。加速因素像复利一样相乘。
然后，当然，您删除了外循环并“兑现”了您获得的所有加速。
如果您想知道这与分析有何不同，那就是通过仔细检查每个堆栈样本以及可能相关的数据，您可以识别可以删除的活动，如果您拥有的只是测量值，那么您只能尝试凭直觉来了解到底是怎么回事。无论进行何种测量，您实际节省的时间就是实际节省的时间。重要的是找到问题所在。无论分析器测量得多么精确，如果你找不到它，你就没有获胜。这些页面上充满了人们说他们要么不明白他们的分析器告诉他们什么，要么似乎在说没有什么可以修复的，而他们非常愿意接受。这是一个有色眼镜的情况。