我正在尝试进行一些墙上时间分析。
GCC在使用-pg进行编译时添加了某些运行时检测代码（例如，用于GProf）。
我认为它在将信息写入gmon.out之前将其存储在某些全局或线程局部数据结构中？
是否可以从代码本身的另一个线程中读取该信息（stacktrace）？ （如果是这样，那么我可以添加我的壁挂时间分析线程而无需自己添加仪器。）
答案 0 :(得分：2)
gprof 不会占用堆栈跟踪，它可以在CPU时间上工作，而不是在墙上时间。 它只是在CPU时间对程序计数器进行采样，并将其归因于它所知道的功能。 与以前的分析器相比，它的主要声誉是，因为仅限PC（“自我时间”）采样在体面大小的应用程序中相当无用，其中调用堆栈是多层深度的， 它还计算任何函数A调用任何函数B的次数。 然后它试图猜测（通过一些非常不稳定的数学运算）可以将多少CPU时间收回到调用较低级别例程的较高级别例程。
有些分析器可以在墙上时间使用堆栈跟踪。 （CPU时间意味着如果你的应用程序通过睡眠，I / O，挂在信号量或其他阻塞上以某种方式将时间浪费在非常低的水平，你将永远不会看到它。） 我知道在墙上时间堆叠采样的那个，即Zoom。 我被告知OProfile可以做到，但我无法验证它。 DTrace也是如此。
但这只是谈论前端，取样。
后端同样重要，向您呈现内容的部分。 通常你会得到“热门路径”，“呼叫图”，“火焰图”等等。
就我个人而言，我对所有这些漂亮的玩具都持怀疑态度。 他们做了什么，他们做得很好，毫无疑问。 但如果加速结果是需要的， 那么最好的信息来自少量的堆栈样本， 在您关心的时间，实际上是查看和理解，而不仅仅是汇总。
没有汇总程序能够比程序员的头脑更好地识别模式， 任何大到足以值得修理的问题都会在少量样本中显现出来。
Here's an example， 和here's another， 如果你想看到它背后的真实数学，look here。