如何分析程序運行時間

Question

我正在嘗試優化c ++程序的性能並減少其運行時間。 但是，我無法弄清楚瓶頸在哪里。

time命令顯示程序本身需要大約5分鍾才能運行，大約5分鍾，用戶cpu時間需要4.5分鍾。

CPU分析器（gcc profiler和google perftool）顯示函數調用在CPU時間中總共需要60秒。 我還嘗試使用分析器來實時采樣而不是cpu時間，它給了我類似的結果。

I / O探查器（我使用過ioapps）也表明I / O只需要大約30秒的程序運行時間。

所以基本上我有3.5分鍾（程序運行時間的最大部分）下落不明，我相信這就是瓶頸所在。

我錯過了什么，如何知道那個時間到了哪里？

Answer 1

正如ÖöTiib建議的那樣，只需在調試器中打破程序即可。 我這樣做是讓程序運行，切換到輸出窗口，鍵入Ctrl-C來中斷程序，切換回GDB窗口，輸入“thread 1”以便在主程序的上下文中，並輸入“bt”以查看堆棧跟蹤。

現在，查看堆棧跟蹤並理解它，因為雖然程序計數器上的指令負責處理該特定循環， 但堆棧上的每個調用也是如此 。

如果你這樣做了幾次，你就會看到確切的線路是造成瓶頸的原因。 一旦你在兩（2）個樣品上看到它，你就已經釘了它。 然后修復它並再次完成所有操作，找到下一個瓶頸，依此類推。 你可以很容易地發現你通過這種方式獲得了巨大的加速。

<火焰>

有人說這正是剖析器所做的，只有他們做得更好。 這就是你在演講廳和博客上聽到的內容，但是這里的交易是：有一些方法可以加速你的代碼，而不是將自己顯示為“慢速函數”或“熱路徑”，例如 - 重新組織數據結構。 即使它具有較高的包容時間百分比，每個功能看起來或多或少都是無辜的。

如果您真正查看堆棧樣本，它們會顯示自己。 因此，好的剖析器的問題不在於樣本的收集， 而在於結果的呈現 。 統計和測量不能告訴你什么樣的小樣本，仔細檢查，告訴你。

小樣本和大量樣本的問題怎么樣？ 不是更好嗎？ 好吧，假設你有一個無限循環，或者如果不是無限循環，它運行的時間比你知道的要長得多？ 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倍。 你不必停在那里。 你可以堅持下去，直到你真的找不到任何東西來解決。

問題越多，潛在的加速越高，但你不能錯過任何一個。 分析器（甚至是好的分析器）的問題在於，通過拒絕您查看和研究單個樣本的機會，它們隱藏了您需要找到的問題。 更多關於這一點。 從統計學角度來看，這是它的工作原理。

有好的剖析師。 最好的是壁掛式堆棧采樣器，它可以報告各行的包含百分比，讓您可以使用熱鍵打開和關閉采樣。 Zoom （ wiki ）就是這樣一個分析器。

但即便是那些人也會錯誤地認為你需要大量的樣品。 你沒有，你為他們支付的價格是你實際上看不到的，所以你不明白為什么花時間，所以你不能輕易分辨是否有必要，你不能除非你知道你不需要它，否則擺脫一些東西。 結果是你錯過了瓶頸，他們最終阻礙了你的加速。

</ flame>