是否有人知道像 gprof 这样的 C 代码分析器，它以微秒而不是毫秒为单位提供函数调用时间？
【问题讨论】：
标签： c profiling profiler execution-time
看看Linux perf。不过，您将需要一个相当新的内核。
【讨论】：
假设你有源代码，让我建议我将如何处理。
知道函数每次调用（包括 I/O）平均花费多长时间，乘以调用次数，再除以总运行时间，即可得出时间分数在该函数的控制下。这部分是您如何知道该函数是否需要花费足够的时间来进行优化。从 gprof 获得这些信息并不容易。
另一种了解在每个函数的控制下花费了多少包含时间的方法是调用堆栈的定时或随机采样。如果一个函数出现在样本的一部分 X 上（即使它在样本中出现多次），那么 X 就是它所占用的时间分数（在误差范围内）。更重要的是，这为您提供每行部分时间，而不仅仅是每个功能。
这部分 X 是您可以获得的最有价值的信息，因为这是您通过优化该函数或代码行可能节省的总时间。
Zoom profiler 是获取此信息的好工具。
我要做的是在顶层代码周围包裹一个长时间运行的循环，以便它重复执行，足够长的时间至少需要几秒钟。然后我会通过随机中断或暂停来手动对堆栈进行采样。实际上只需要很少的样本（例如 10 或 20 个）就可以真正清楚地了解最耗时的函数和/或代码行。
附：如果您担心统计准确性，让我来量化一下。如果一个函数或代码行恰好有 50% 的时间在堆栈上，并且您采集 10 个样本，那么显示它的样本数将为 5 +/- 1.6，误差率为 16%。如果实际时间更小或更大，误差范围就会缩小。您还可以通过采集更多样本来降低误差范围。要获得 1.6%，需要 1000 个样本。实际上，一旦发现问题，您就可以决定是否需要更小的误差范围。
【讨论】：
oprofile 为您提供时钟分辨率的时间，即纳秒，它生成与 gprof 兼容的输出文件，使用起来非常方便。
【讨论】：
gprof 以毫秒或微秒为单位给出结果。我不知道确切的理由，但我的经验是，当它认为有足够的精度时，它会在微秒内显示结果。要获得微秒级的输出，您需要运行程序更长的时间和/或没有任何需要花费太多时间运行的例程。
【讨论】：