使用带插座的gprof

套接字代码需要处理 中断的系统调用 不管分析器是什么,但是在分析器下是不可避免的。这意味着拥有类似代码。

if ( errno == EINTR ) { ...

每次系统调用后。

举个例子, here 作为背景。

GPROF ( here's the paper )是可靠的,但是 only was ever intended to measure changes 即使如此,它也只测量CPU绑定的问题。它从未被宣传过对 定位问题 . 这是一个想法,其他人在它上面分层。

考虑 this method .

另一个好的选择是,如果你不介意花点钱的话, Zoom .

补充: 如果我能举个例子。假设您有一个调用层次结构,其中main调用若干次,a调用b若干次,b调用c若干次,c用套接字或文件等待一些I/O,这基本上就是程序所做的一切。现在,进一步假设每个例程调用下一个例程的次数比实际需要的次数多25%。因为1.25^3大约是2,这意味着整个程序的运行时间是实际需要的两倍。

首先,因为所有的时间都花在等待I/O上,gprof不会告诉您如何花费时间,因为它只关注“运行”时间。

第二,假设 做 计算I/O时间。它可以给你一个调用图,基本上说每个例程需要100%的时间。这告诉你什么?你已经知道了。

但是,如果您获取少量的堆栈示例,您将在每个示例上看到每个例程调用下一个示例的代码行。 换句话说,这不仅仅是给你一个粗略的时间百分比估计,而是 将您指向特定的代码行,这些代码行成本高昂 . 您可以查看每一行代码,并询问是否有方法减少执行次数。假设你这样做,你会得到2的加速系数。

人们通过这种方式得到大的因素。根据我的经验,呼叫级别的数量可以轻松达到30个或更多。每次通话 似乎 必要的,直到你问是否可以避免。即使是少量的可避免调用也会对许多层产生巨大的影响。