gprof(here's the paper)是可靠的,但它只是用来衡量变化,即使如此,它也只衡量 CPU 绑定的问题。从来没有宣传它对定位问题有用。这是其他人在其之上分层的想法。
考虑这种方法。
如果您不介意花一些钱,另一个不错的选择是Zoom。
补充:如果我能给你举个例子。假设你有一个调用层次结构,其中 Main 调用 A 一些次,A 调用 B 一些次,B 调用 C 一些次,C 等待一些带有套接字或文件的 I/O,基本上就是这样该程序确实如此。现在,进一步假设每个例程调用下一个例程的次数比实际需要的次数多 25%。由于 1.25^3 大约是 2,这意味着整个程序的运行时间是实际需要的两倍。
首先,由于所有时间都花在等待 I/O 上,因此 gprof 不会告诉您该时间是如何花费的,因为它只查看“运行”时间。
其次,假设(只是为了论证)它确实计算了 I/O 时间。它可以给你一个调用图,基本上说每个例程需要 100% 的时间。这告诉你什么?没有什么比你已经知道的更多了。
但是,如果您获取少量堆栈样本,您将在每个样本上看到每个例程调用下一个例程的代码行。换句话说,它不仅仅是给你一个粗略的百分比时间估计,它还指向你昂贵的特定代码行。您可以查看每一行代码并询问是否有办法减少执行次数。假设你这样做,你将获得 2 倍的加速。
人们通过这种方式获得重要因素。根据我的经验,呼叫级别的数量很容易达到 30 或更多。每个电话似乎都是必要的,直到您询问是否可以避免。即使是少量可避免的调用也会对那么多层产生巨大影响。