如何解决如何使用 perf 或其他实用程序来测量循环/函数的经过时间
我正在处理一个需要首先分析目标应用程序的项目。
我想知道的是循环体/函数消耗的确切时间。平台为BeagleBone Black board，Debian OS，安装perf_4.9。
gettimeofday() 可以提供微秒级的分辨率，但我仍然想要更准确的结果。看起来 perf 可以提供周期统计数据，因此非常适合用于目的。但是，perf 只能分析整个应用程序，而不能分析单个循环/函数。
尝试了此Using perf probe to monitor performance stats during a particular function中发布的说明后，效果不佳。
我只是想知道是否有任何 C 语言示例应用程序我可以在此板上测试和使用以达到我的目的。谢谢！
解决方法
警告：这更多的是评论而不是答案，但只是评论有点太长了。
非常感谢您为新功能提供建议。我试过了，但有点不确定它的准确性。是的，它可以提供纳秒级分辨率，但存在不一致。
如果您使用两个不同的时钟源，将会不一致。
我首先使用clock_gettime()来测量一个循环体，这样大约经过的时间大约是1.4us。然后我在循环体的开始和结束处分别放置GPIO指令，拉高和下拉，并用示波器测量这个GPIO上的信号频率。
范围很有用如果您正在尝试调试硬件。它还可以显示引脚上的内容。但是，在 40 多年的性能测量/改进/调优工作中，我从未用它来调优软件。
事实上，我更相信 CPU 时钟，而不是我相信软件性能数字的范围
对于生产产品，您可能需要测量部署在客户站点的系统的性能[因为问题只出现在该客户的机器上]。您可能必须远程调试它并且无法在那里连接示波器。因此，您需要能够无需外部探头/测试台即可工作的东西。
令我惊讶的是，频率约为 1.8MHz，即 ~500ns。这种不一致让我有点困惑...... – GeekTao
差异可能只是基于不同的时基和进入/退出设备（GPIO 引脚）延迟的舍入误差。我认为您只是以这种方式使用 GPIO 来促进基准测试/计时。因此，在某种程度上，您不是测量“真实”系统，而是具有 GPIO 开销的系统。
在调优中，与相对值相比，人们不太关心绝对值。也就是说，clock_gettime 最终基于高分辨率时钟滴答的数量（1ns/滴答或来自系统自由运行的 TSC（时间戳计数器）更好）。时钟频率实际上是什么并不重要。如果您测量循环/函数并获得 X 持续时间。然后，您更改一些代码并得到 X+n，这会告诉您代码是变快了还是变慢了。
500ns 不是很大。几乎任何系统范围的操作（例如时间切片、系统调用、任务切换等）都可以解释这一点。除非您已将 GPIO 寄存器映射到应用内存中，否则系统调用开销可能会使它相形见绌。
事实上，只需调用 clock_gettime 的开销就可以解决这个问题。
虽然 clock_gettime 在技术上是一个系统调用，但 linux 会通过 VDSO 机制将代码直接映射到应用程序的代码中，因此没有系统调用开销。但是，即使是用户空间代码也有一些计算要做。
例如，我有两台 x86 PC。在一个系统上，调用的开销是 26 ns。在另一个系统上，开销是 1800 ns。这两个系统都至少为 2GHz+
对于您的 beaglebone/arm 系统，基本时钟速率可能较低，因此 500 ns 的开销可能是大概的。
我通常对开销进行基准测试并将其从计算中减去。
而且，在 x86 上，实际代码只是获取 CPU 的 TSC 值（通过 rdtsc 指令）并进行一些调整。对于 arm，它有一个类似的 H/W 寄存器，但需要特别注意将用户空间访问映射到它（协处理器指令，IIRC）。
说到 arm，我正在做一个商业 arm 产品（确切地说是 nVidia Jetson）。我们非常担心传入视频帧的延迟。
硬件工程师不信任 TSC [或一般软件 ;-)] 并试图使用示波器、LED [由 GPIO 引脚控制] 并且当 LED 闪烁/脉冲出现在视频帧（例如，视频帧中白点的坐标[实际上]是一种时间测量）。
说服工程师花了一些时间，但最终我能够证明clock_gettime/TSC 方法更准确/可靠。
而且，当然，更容易使用。我们有多个测试/开发/SDK 板，但一次只能在一个上连接示波器/LED 设备。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
