我习惯于随机暂停 gdb 中正在运行的程序，以了解它在哪里花费时间，如 How can I profile C++ code running in Linux? 中所述。这种技术似乎最适合批处理，而不是交互式/实时系统。
对于我目前正在处理的一个程序，绝大多数样本都在 epoll_wait() 中。这显然不是加速的候选者，但我想知道其他性能瓶颈是什么。
理想情况下，我想要一种在线程未被 epoll_wait() 阻塞的时间间隔中生成多个堆栈跟踪（连同参数，可能还有环境）的方法。
有谁知道这样做的好方法，还是我应该硬着头皮改用分析器？
【问题讨论】：
标签： performance gdb profiling
对于我目前正在开发的项目，绝大多数 样本在 epoll_wait() 中。这显然不是一个候选人 加速，但我想知道其他性能瓶颈 是。
我认为你可以使用poor man's profiler。
在它的输出中，您应该会在顶行看到带有epoll_wait 的折叠堆栈跟踪。您已经知道它不是代码中的瓶颈，因此您应该跳过它并查看下一行输出以查看更合适的优化候选者。
【讨论】：
我在 UI 程序中使用随机暂停。我在调试器下运行整个事情，并且只在需要时间时暂停它，即当我等待它时。
如果你看到它登陆epoll_wait，调用堆栈应该说明它为什么等待。
是否有可能它正在执行您可能会避免的 I/O？
如果你无法避免 I/O，那么你只需要一个 I/O-bound 程序。
我见过的情况是在应用程序启动期间似乎需要很长时间。 堆栈示例通常显示它在加载插件时有 30 多个级别。 如果我阅读堆栈，我会看到作为加载插件的一部分，它会从 dll 中提取一个字符串资源，以获取插件的 name，然后根据它所在的国家/地区进行翻译。 这样做的原因是它可以绘制一个类似“Loading Plugin FooBar”的字符串，这样用户就会知道为什么要花这么长时间。
它可以将启动时间增加 2 倍，这样它就可以告诉用户为什么它很慢！
不用说，修复它并不难......
其他问题类似。 注意：即使是挂钟时间，仅通过知道包含时间函数需要多少时间，您也无法获得任何这种洞察力。 这就是暂停和任何其他分析方法之间的区别。 它告诉你为什么，没有它你就无法判断这个活动是否是不必要的。
【讨论】：