无论分析器如何，套接字代码都需要处理中断的系统调用，但在分析器下这是不可避免的。这意味着拥有类似的代码。
if ( errno == EINTR ) { ...
在每次系统调用之后。
例如，看一下这里的背景。
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 或更多。每个电话似乎都是必要的，直到您询问是否可以避免。即使是少量可避免的调用也会对那么多层产生巨大影响。