基于文本的分析结果查看器
您知道用于查看应用程序分析结果的基于文本的应用程序吗？分析结果基本上包含 C++ 函数调用回溯的列表以及遇到这些回溯的频率；现在我正在寻找一个控制台工具来分析原始数据（哪个回溯最常发生；哪个函数被最常调用，独立于调用跟踪......）。
到目前为止，我已经从原始数据创建了与 callgrind 兼容的文件，然后使用优秀的 KCachegrind 工具进行分析；但现在我也在寻找一种无需在基于文本的终端上即可工作的工具。有什么想法吗？
Do you know of a text-based application for viewing results of application profiling? The profiling results basically contain a list of C++ function call backtraces and how often these backtraces were encountered; now I'm looking for a console tool to analyze the raw data (which backtrace occurred most often; which function was called most often, independent of call trace...).
So far I've created callgrind-compatible files from the raw data and then used the excellent KCachegrind tool for analysis; but now I'm also looking for a tool that works without on text-based terminal. Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看看
callgrind_annotate。Take a look at
callgrind_annotate.我曾经写过这样一个查看器。它专注于一行代码，显示通过该行运行的样本的百分比，以及允许转换到上级或下级代码行的蝴蝶视图。
它做了一个很好的演示，但我真的使用过它吗？不会太久。
（我假设堆栈样本是在您希望加速的时间间隔内获取的，即不是在用户等待期间获取的。）
问题是，程序可能在那段时间做了一些浪费的事情。 （如果不是，则无法加快速度。）
不管浪费的事情是什么，它都是由一些出于不良原因而花费的时间组成的，比如 10%、50%、90% 或其他什么。在此期间，它位于堆栈上，因此对堆栈样本的检查将显示它。
而且，您不必查看太多内容。如果某件事花费了 50% 的时间，则 1000 个样本将在大约 500 个样本上显示它，而 10 个样本将在大约 5 个样本上显示它。样本数量较多时，将以额外的精度来估计百分比。如果您的目标是隔离问题以便修复它，则不需要那个额外的数字。
因此，一个可以按行显示通过该行的堆栈样本百分比的工具非常有用 。很好的东西，因为浪费的代码会出现在上面，显示百分比。
它没有向您显示该语句被执行的原因，这就是您如何知道它是否浪费的原因。查看堆栈上语句的上下文确实可以告诉您这一点。
因此，尽管我有观察器，但我最终只是检查了样本本身，而且只检查了大约 10 或 20 个样本。百分比越大，在找到它之前需要查看的样本数量就越少。 这是一个示例。
I wrote such a viewer once. It focussed on a line of code, showing the percent of samples running through that line, and a butterfly view allowing transitions to superior or subordinate lines of code.
It made a nice demo, but did I really use it? Not for long.
(I'm assuming the stack samples have been taken during the interval that you wish to speed up, i.e. not during user-wait.)
The thing is, the program is probably doing something wasteful in that time. (If it is not, you can't speed it up.)
Whatever that wasteful thing is, it consists of some percent of time being spent for poor reasons, like 10%, 50%, 90%, or whatever. During that time, it is on the stack, so an examination of the stack samples will show it.
And, you don't have to look at very many of them. If something is taking 50% of time, 1000 samples will show it on about 500, and 10 samples will show it on about 5. The larger number of samples will estimate the percentage with an extra digit of precision. If your goal is to isolate the problem so you can fix it, you don't need that extra digit.
So, a tool that shows you, by line, the percent of stack samples going through that line is a very nice thing to have, because the wasteful code will appear on it, showing the percentage.
What it does not show you is the reason why the statement is being executed, which is how you know if it's wasteful. Looking at the statement's context on the stack does tell you that.
So even though I had the viewer, I just ended up examining the samples themselves, and only about 10 or 20 of them. The bigger the percentage is, the smaller the number of samples I need to look at before I find it. Here's an example.