我正在尝试优化c ++程序的性能并减少其运行时间。但是，我无法弄清楚瓶颈在哪里。
time命令显示程序本身运行大约需要5分钟，大约5分钟，用户cpu时间需要4.5分钟。
CPU分析器（gcc profiler和google perftool）显示函数调用在CPU时间中总共需要60秒。我还尝试使用分析器来实时采样而不是cpu时间，它给了我类似的结果。
I / O分析器（我使用的是ioapps）也表明I / O只需要大约30秒的程序运行时间。
所以基本上我有3.5分钟（程序运行时间的最大部分）下落不明，我相信这就是瓶颈所在。
我错过了什么，如何知道那个时间到了哪里？
答案 0 :(得分：7)
正如ÖöTiib建议的那样，只需在调试器中打破程序即可。我这样做是让程序运行，切换到输出窗口，键入Ctrl-C来中断程序，切换回GDB窗口，输入“thread 1”以便在主程序的上下文中，并输入“bt”以查看堆栈跟踪。
现在，查看堆栈跟踪并理解它，因为虽然程序计数器上的指令负责所花费的特定循环，但堆栈上的每个调用都是。
如果你这样做了几次，你就会看到确切的线路是造成瓶颈的原因。 一旦你在两（2）个样品上看到它，你就已经钉了它。 然后修复它并再次完成所有操作，找到下一个瓶颈，依此类推。 你很容易发现你以这种方式获得了巨大的加速。
＆LT;火焰＆GT;
有些人说这正是剖析师所做的，只有他们做得更好。 这就是你在演讲厅和博客上听到的，但这是交易： 有一些方法可以加速您的代码，例如，不会将自己显示为“慢速函数”或“热路径” - 重新组织数据结构。 即使具有较高的包容性时间百分比，每个功能看起来都或多或少是无辜的。
如果您实际查看堆栈样本，它们会显示自己。 因此，好的分析器的问题不在于样本集合，它在结果的呈现中。统计和测量不能告诉你什么样的小样本，仔细检查，告诉你。
小样本和大量样本的问题怎么样？不是更好吗？ 好吧，假设你有一个无限循环，或者如果不是无限循环，它运行的时间比你知道的要长得多？ 1000个堆叠样本会发现它比单个样本更好吗？ （不）如果你在调试器下看它，你知道你在循环中，因为它基本上占用了100％的时间。它位于堆栈的某个位置 - 只需扫描堆栈直到找到它。 即使循环只占50％或20％的时间，这就是每个样本看到它的概率。 所以，如果你看到一些你可以在两个样本上摆脱的东西，那就值得去做。 那么，1000个样品会给你买什么？
也许有人会这样想：“那么如果我们错过一两个问题怎么办呢？也许它已经足够好了。”好吧，是吗？ 假设代码有三个问题P占50％的时间，Q占25％，R占12.5％。好东西叫做A. 这表示如果您修复其中一个，其中两个或全部三个，您获得的加速。
PRPQPQPAPQPAPRPQ original time with avoidable code P, Q, and R all mixed together
RQQAQARQ fix P - 2 x speedup
PRPPPAPPAPRP fix Q - 1.3 x "
PPQPQPAPQPAPPQ fix R - 1.14 x "
RAAR fix P and Q - 4 x "
QQAQAQ fix P and R - 2.7 x "
PPPPAPPAPP fix Q and R - 1.6 x "
AA fix P, Q, and R - 8 x speedup
这是否清楚说明为什么那些“逃脱”的人真的受伤？ 如果你错过了最好你可以做的是慢两倍。
如果您检查样品，很容易找到它们。 P是样品的一半。 如果您修复P并再次执行，则Q是一半样本。一旦你修复Q，R就是一半的样本。 修复R，你的速度提高了8倍。 你不必停在那里。你可以坚持下去，直到找不到任何可以修复的东西。
问题越多，潜在加速越高， 但你不能错过任何一个。 分析器（甚至是好的分析器）的问题在于，通过拒绝您查看和研究单个样本的机会，它们隐藏了您需要找到的问题。 More on all that. For the statistically inclined, here's how it works.
有很好的个人资料。 最好的是壁挂式堆栈采样器，它可以报告各行的包含百分比，让您可以使用热键打开和关闭采样。 Zoom（wiki）就是这样的探查者。
但即便是那些人也会错误地认为你需要大量的样本。 你没有，而且你为他们支付的价格是你实际上看不到的，所以你看不到为什么花费的时间，所以你不能轻易分辨出它是不是必要， 除非你知道你不需要它，否则你无法摆脱某些东西。 结果是你错过了瓶颈，他们最终阻碍了你的加速。
＆LT; /火焰＆GT;