評估callgrind呼叫配置文件的工具？

Question

某種程度上與this question有關，您建議使用哪種工具來評估使用callgrind創建的分析數據？

它不必具有圖形界面，但它應該以簡明，清晰和易於解釋的方式準備結果。我知道例如kcachegrind，但該程序缺少一些功能，例如所顯示錶格的數據導出或僅從顯示屏複製行。

Answer 1

幾年前，我寫了一個分析器在DOS下運行。

如果您使用的是KCacheGrind，那麼我會這麼做。編寫它可能不會太困難，或者您可以手動完成。

KCacheGrind有一個工具欄按鈕「強制轉儲」，您可以隨時手動觸發轉儲。在等待程序的時間間隔內，隨機或僞隨機時間捕獲堆棧跟蹤是技術的核心。

需要很少的樣本--20通常綽綽有餘。如果瓶頸成本很高，比如超過50％，那麼5個樣品可能就足夠了。

樣品的處理非常簡單。每個堆棧跟蹤由一系列代碼（實際上是地址）組成，除了最後一個都是函數/方法調用。

• 收集出現在樣品上，並消除重複的代碼的所有行的列表。

• 對於每一行代碼，請計算它顯示的樣本的小數部分。例如，如果您抽取20個樣本，並且其中的3個樣本出現代碼行，即使它在某個樣本中出現多次（由於遞歸），計數爲3/20或15％。這是直接衡量每項聲明的成本。

• 顯示代價最高的100行代碼。你的瓶頸在列表中。

我通常做這個信息是選擇具有高性價比的線路，然後直到它出現手動堆取樣品（或看我已經得到的那些），並問自己「爲什麼它正在執行這一行代碼，不僅在本地意義上，而且在全局意義上。「另一種說法是「從全球意義上說，當樣本被採集時，程序試圖在時間片上完成什麼」。我問這個問題的原因是因爲它告訴我是否真的有必要花費那些費用。

我不希望所有偉大的工作人員的關鍵都開發廓線儀，但遺憾的是有很多根深蒂固的神話關於這個問題，其中包括：

• 是精確的測量，與很多樣品很重要。重點應該放在找到的瓶頸。精確的測量不是這個的先決條件。對於典型的瓶頸，成本在10％到90％之間，測量可能非常粗糙。

• 功能比代碼行更重要。如果你發現一個昂貴的功能，你仍然需要在其中搜索瓶頸。該信息就在那裏，在堆棧追蹤 - 無需尋找它。

• ，你需要區分掛鐘時間CPU。如果你在等待它，這是掛鐘時間（手錶時間？）。例如，如果你有一個由無關的I/O組成的瓶頸，你是否想忽略它，因爲它不是CPU時間？

• 獨佔時間和包含時間之間的區別是非常有用的。只有在計時功能的情況下才有意義，並且您想知道時間是否花在了被叫方身上。如果你看看代碼行，唯一重要的是包容性時間。另一種說法是，每條指令都是一條調用指令，即使它只調用微碼。

• 是遞歸的問題。這是無關緊要的，因爲它不會影響線路所在樣品的分數，因此是負責任的。

• 說的行或函數事項的調用計數。無論是速度快還是被稱爲次數過多，或者變慢並被調用一次，成本就是它使用的時間百分比，這就是堆棧樣本估計的結果。

• 說的抽樣事宜性能。假設不會造成瓶頸移動，我不介意在繼續前拿一個堆棧樣本並觀察它幾分鐘。

Here's更完整的解釋。

Answer 2

有與callgrind數據工作的一些CLI工具：

callgrind_annotate 

和cachegrind工具，它可以顯示來自callgrind.out

cg_annotate 

一些信息