Callgrind：调用图生成缓存和分支预测分析器
目錄
6.1。概觀要使用此工具，必須--tool=callgrind在Valgrind命令行上指定?。
6.1。概觀
Callgrind是一個分析工具，可以將程序運行中的函數之間的通話記錄作為調用圖記錄。默認情況下，收集的數據由執行的指令數，它們與源行的關系，函數之間的調用者/被調用者關系以及這些調用的數量組成。可選地，高速緩存模擬和/或分支預測（類似于Cachegrind）可以產生關于應用的運行時行為的更多信息。
在程序終止時，將配置文件數據寫入文件。為了呈現數據，并對分析進行交互式控制，提供了兩個命令行工具：
callgrind_annotate該命令讀入配置文件數據，并打印排序的功能列表，可選地使用源注釋。
對于數據的圖形可視化，請嘗試?KCachegrind，它是基于KDE / Qt的GUI，可以輕松導航Callgrind生成的大量數據。
此命令使您能夠交互地觀察和控制當前在Callgrind的控制下運行的程序的狀態，而不停止程序。您可以獲取統計信息以及當前的堆棧跟蹤，您可以請求歸零或轉儲配置文件數據。
6.1.1。功能
Cachegrind收集平面配置文件數據：事件計數（數據讀取，高速緩存未命中等）直接歸因于其發生的功能。此成本歸屬機制稱為自身或排?他歸屬。
Callgrind通過在功能調用邊界傳播成本來擴展此功能。如果功能foo調用?bar，則將成本bar加入?foo成本中。當應用于整個程序時，它建立了所謂的包容性?成本的圖片，即每個功能的成本包括直接或間接的所有功能的成本。
作為一個例子，包容成本?main應該幾乎是總計費用的100％。由于main運行之前產生的成本?，例如運行時鏈接器的初始化和全局C ++對象的構建，其包容成本main?并不完全為總程序成本的100％。
與呼叫圖一起，您可以從main其中大部分程序的成本開始找到特定的呼叫鏈?。來電/被叫成本歸屬對于從多個呼叫站點調用的分析功能也是有用的，其中優化機會取決于呼叫者中更改的代碼，特別是通過減少呼叫計數。
Callgrind的緩存模擬是基于Cachegrind的。首先閱讀Cachegrind的文檔：緩存和分支預測分析器。下面的內容描述了除了Cachegrind的功能之外支持的功能。
Callgrind檢測函數調用和返回的能力取決于運行平臺的指令集。它在x86和amd64上效果最好，不幸的是，目前在PowerPC，ARM，Thumb或MIPS代碼上并不能很好地工作。這是因為在這些指令集中沒有明確的調用或返回指令，所以Callgrind必須依賴啟發式來檢測調用和返回。
6.1.2。基本用法
與Cachegrind一樣，您可能想要使用調試信息（-g選項）進行編譯，并且優化已打開。
要啟動程序的配置文件運行，請執行：
valgrind --tool = callgrind [callgrind options]你的程序[程序選項]當模擬運行時，您可以通過以下方式觀察執行：
callgrind_control -b這將打印出當前的回溯。要使用事件計數注釋回溯，請運行
callgrind_control -e -b程序終止后，將生成一個名為的配置文件數據文件?callgrind.out.<pid>?，其中pid是要分析的程序的進程ID。數據文件包含有關執行功能的程序中進行的調用以及?指令讀取（Ir）事件計數的信息。
要從配置文件數據文件生成功能函數摘要，請使用
callgrind_annotate [options] callgrind.out。<pid>此摘要類似于使用cg_annotate從Cachegrind運行得到的輸出：函數列表按功能的排他成本排序，這也是顯示的。Callgrind的其他功能重要是以下兩個選項：
-
--inclusive=yes：不使用功能的獨占成本作為排序順序，使用并顯示包含成本。
-
--tree=both：交叉進入頂級功能列表，每個功能的呼叫者和被呼叫者的信息。在這些代表執行的呼叫的行中，成本給出了在呼叫中花費的事件數。縮進，在每個功能之上，有呼叫者列表，以及下面的被叫列表。給定功能（呼叫者線路）的呼叫中的事件總和以及來自函數（被叫線路）的呼叫中的事件的總和以及自身成本給出了該功能的總包含成本。
使用--auto=yes獲得注釋的源代碼，它的源可以找到所有相關功能。除了生成的源注釋外?cg_annotate，您還可以看到具有呼叫計數的帶注釋的呼叫站點。有關所有其他選項，請參閱（Cachegrind）文檔?cg_annotate。
為了更好的通話圖瀏覽體驗，強烈建議您使用KCachegrind。如果您的代碼的周期成本（以遞歸方式相互調用的函數集合）的大部分成本，則必須使用KCachegrind，因為callgrind_annotate?目前不執行任何循環檢測，這在本例中獲得正確的結果很重要。
如果您還有興趣測量程序的緩存行為，請使用Callgrind選項?--cache-sim=yes。對于分支預測模擬，使用--branch-sim=yes。預計進一步放緩約2倍。
如果您要配置文件的程序段位于運行中間，則無需任何概要分析即可?快速轉到此部分，然后啟用概要分析是有益的。這通過使用命令行選項?--instr-atstart=no?并在shell中運行：?callgrind_control -i on在有趣的代碼部分執行之前實現。要精確指定分析應該開始的代碼位置，請使用客戶端請求CALLGRIND_START_INSTRUMENTATION。
如果您想要看到匯編代碼級別的注釋，請指定?--dump-instr=yes。這將以指令粒度產生配置文件數據。請注意，生成的配置文件數據只能使用KCachegrind進行查看。對于匯編注釋，還可以看到函數內的控制流的更多細節，即（條件）跳轉也是有趣的。這將通過進一步指定來收集?--collect-jumps=yes。
6.2。高級用法
6.2.1。從一個程序運行多次分析轉儲
有時您對整個程序運行的特性不感興趣，但只對其一小部分感興趣，例如執行一個算法。如果存在多種算法，或者一種算法運行不同的輸入數據，則為單個程序運行的不同部分獲取不同的配置文件信息甚至是有用的。
配置文件數據文件具有表單名稱
callgrind.out。PID。part - threadID其中pid是運行程序的PID，部分是在每個轉儲上遞增的數字（在程序終止時跳過“part”用于轉儲），?threadID是一個線程標識（“-threadID”僅在您請求時使用單個線程的轉儲--separate-threads=yes）。
在Callgrind的監督下運行程序時，有多種方式可以生成多個配置文件轉儲。然而，所有方法都會觸發相同的操作，即“自上次轉儲或程序啟動以來的所有配置文件信息，以及零成本計數器之后”。為了允許調零成本計數器而不傾倒，第二個動作是“現在零成本計數器”。不同的方法是：
-
轉儲程序終止。?這種方法是標準的方式，您不需要任何特殊的操作。
-
自發，互動傾銷。使用
callgrind_control -d [hint [PID / Name]]請求使用PID或Name轉儲受監督應用程序的配置文件信息。?提示是一個任意字符串，您可以選擇指定以后能夠區分配置文件轉儲。轉儲完全寫入之前，控制程序將不會終止。請注意，應用程序必須正在運行才能檢測dump命令。因此，對于GUI應用程序，請調整窗口大小或服務器的大小，發送請求。
如果您使用KCachegrind?瀏覽配置文件信息，可以使用工具欄按鈕強制轉儲。這將在轉儲寫入后請求轉儲并觸發重新加載。
-
執行指定數量的基本塊后定期轉儲。為此，請使用命令行選項--dump-every-bb=count。
-
在進入/離開指定功能時傾倒。?使用選項--dump-before=function?和--dump-after=function。在進入功能之前要調零成本計數器，請使用?--zero-before=function。
您可以為不同的功能多次指定這些選項。函數規范支持通配符：例如?--dump-before='foo*'，在輸入任何以foo開頭的函數之前，用來生成轉儲?。
-
程序控制傾銷。?插入?CALLGRIND_DUMP_STATS;?到代碼中您想要進行配置文件轉儲的位置。使用?CALLGRIND_ZERO_STATS;僅零輪廓計數器。有關Callgrind特定客戶端請求的更多信息，請參閱客戶端請求參考。
如果您正在運行多線程應用程序并指定命令行選項--separate-threads=yes，則會自動對每個線程進行概要分析，并創建自己的配置文件轉儲。因此，最后兩個方法將僅生成當前正在運行的線程的一個轉儲。使用其他方法，您將在轉儲請求上獲得多個轉儲（每個線程一個）。
6.2.2。限制收集事件的范圍
默認情況下，每當事件發生時（例如指令執行或緩存命中/未命中），Callgrind會將它們聚合到事件計數器中。但是，您可能只對給定功能中發生的情況或從給定的程序階段開始感興趣。為此，您可以禁用不感興趣的程序部件的事件聚合。事件歸功于功能以及每個程序階段產生單獨的輸出都可以通過其他方法來完成（見上一節），禁用聚合有兩個好處。首先，這是非常精細的（例如僅用于函數內的循環）。第二，valgrind --tool=none
有兩個方面影響了Callgrind在程序執行的某個時間點聚合事件。首先是收集狀態。如果這是關閉，則不會進行聚合。通過更改收集狀態，可以非常精細地控制事件聚合。然而，Callgrind的執行速度沒有多大的區別。默認情況下，收集被打開，但可以通過不同的方式被禁用（見下文）。其次，Callgrind正在運行的儀器模式。此模式可以打開或關閉。如果儀器關閉，則不會對程序中的操作進行任何觀察，因此不會將任何操作轉發給可能觸發事件的模擬器。到底，?不會匯總任何事件。巨大的好處是儀器關閉的速度要高得多。然而，這只應該謹慎使用，并且粗略地使用：每個模式更改都會重置模擬器狀態（即，內存塊是否被緩存），并刷新Valgrinds內部高速緩存的測試代碼塊，從而在切換時產生延遲損失時間。此外，由于識別出的高速緩存未命中，因此在切換儀表后，緩存模擬器的結果將會發生偏移（如果您關心這種預熱效果，那么您應該確保在轉換儀器后立即關閉收集狀態模式開啟）。然而，切換儀器狀態對于跳過更大的程序階段（如初始化階段）非常有用。默認情況下，儀器打開，但與收集狀態一樣，可以通過各種方式進行更改。
Callgrind可以通過指定選項關閉儀器模式--instr-atstart=no。之后，儀器可以通過兩種方式進行控制：首先，與
callgrind_control -i on（并通過指定“關”而不是“開”）再次關閉）。其次，儀表狀態可以用編程宏改變CALLGRIND_START_INSTRUMENTATION;?和CALLGRIND_STOP_INSTRUMENTATION;。
類似地，程序啟動時的收集狀態可以被關閉--instr-atstart=no。在執行期間，可以使用宏程序控制CALLGRIND_TOGGLE_COLLECT;。此外，您可以通過使用限制事件收集到特定的功能--toggle-collect=function。這將在進入和離開指定的功能時切換收集狀態。當此選項生效時，程序啟動時的默認收集狀態為“off”。只有在給定功能內部運行的事件才會被收集。給定函數的遞歸調用不會觸發任何操作。可以多次給出此選項以指定不同的興趣功能。
6.2.3。計算全球巴士事件
為了在多線程代碼中的線程之間訪問共享數據，需要進行同步以避免競爭條件。同步原語通常通過原子指令來實現。但是，過度使用這些說明可能會導致性能問題。
為了能夠分析這個問題，Callgrind可以選擇性地對所執行的原子指令數進行計數。更準確地說，對于x86 / x86_64，這些是使用鎖前綴的指令。對于支持LL / SC的架構，這些是執行的SC指令的數量。對于這兩者，使用“全球公共汽車事件”一詞。
用于全局總線事件的事件類型的短名稱是“Ge”。計數全球總線事件，使用--collect-bus=yes。
6.2.4。避免循環
非正式地，循環是一組以遞歸方式相互呼叫的函數。
正式地說，一個循環是一個非空的函數集合S，使得對于S中的每對函數F和G，可以從F到G（可能經由中間函數）以及從G到F調用。此外， S必須是最大的 - 也就是滿足該屬性的最大函數集。例如，如果從S內部調用第三函數H并調用S，則H也是循環的一部分，并且應包括在S中。
遞歸在程序中很常見，因此循環有時會出現在Callgrind的調用圖輸出中。但是，本章的標題應該提出兩個問題：循環是什么壞事，這使你想避免這些問題？并且：如何避免循環而不改變程序代碼？
周期本身并不差，但往往使您的代碼的性能分析更加困難。這是因為一個周期內的通話費用是無意義的。包容性成本的定義，即功能的自身成本加上被調用者的包容性成本，需要功能之間的拓撲順序。對于循環，這并不適用：循環中的函數的被調用者包括函數本身。因此，KCachegrind會循環檢測并跳過循環內調用的任何包含成本的可視化。此外，循環中的所有功能都被折疊成類似的人工功能Cycle 1。
現在，當一個程序暴露出很大的周期（對于一些GUI代碼，或者一般使用事件或基于回調的編程風格的代碼），你會失去漂亮的屬性，讓您通過跟蹤調用鏈來定位瓶頸?main，包容成本。此外，KCachegrind失去了顯示通話圖的有趣部分的能力，因為它使用包容性成本來切斷不感興趣的區域。
盡管循環中包含成本是無意義的，但可視化的最大缺點是可能暫時關閉KCachegrind中的循環檢測，這可能導致誤導性的可視化。然而，由于獨立調用鏈的不合邏輯疊加，通常會出現循環，因為配置文件結果將會看到一個循環。以非常小的測量包容成本忽略不感興趣的電話會破壞這些周期。在這種情況下，通過不檢測循環的不正確處理仍然給出有意義的分析可視化。
必須注意的是，目前，callgrind_annotate?根本沒有執行任何循環檢測。對于具有函數遞歸的程序執行，例如可以打印100％以上的無含義成本。
在描述為什么周期不利于分析時，值得一提的是循環避免。這里的主要觀點是，配置文件數據中的符號不??一定與程序中找到的符號完全一致。相反，符號名稱可以編碼來自當前執行上下文的附加信息，例如當前函數的遞歸級別，或甚至導致該函數的調用鏈的某些部分。盡管將附加信息編碼到符號中能夠避免周期，但必須小心使用，以免引起符號爆炸。后者為Callgrind提供了可能的內存不足條件和大型數據文件的大量內存需求。
在Callgrind的簡檔數據輸出中避免循環的另一個可能性是簡單地省略調用圖中的給定函數。當然，這也會忽略來自和忽略的功能的任何呼叫信息，從而可以打破一個周期。候選人通常是事件驅動代碼中的調度程序函數。忽略對函數的調用的選項是?--fn-skip=function。除了可能的中斷周期之外，這在Callgrind中用于跳過PLT部分中的蹦床功能，用于調用共享庫中的函數。你可以看到差異，如果你的配置文件--skip-plt=no。如果一個呼叫被忽略，其成本事件將被傳播到封閉的功能。
如果您有遞歸函數，您可以通過指定來區分前10個遞歸級別?--separate-recs10=function。或者對于所有功能?--separate-recs=10，但這會給你更大的配置文件數據文件。在配置文件數據中，您將看到“func”的遞歸級別作為名稱為“func”，“func'2”，“func'3”等的不同功能。
如果您的程序中有“A> B> C”和“A> C> B”的調用鏈，則通常會得到“假”循環“B <> C”。使用?--separate-callers2=B?--separate-callers2=C和功能“B”和“C”將視為不同的功能，具體取決于直接來電者。使用撇號將這個“上下文”附加到函數名中，你會得到“A> B'A”C'B“和”A> C'A“B'C”，并且不會有循環。使用?--separate-callers=2以獲取所有功能的2呼叫者的依賴。請注意，這樣做會增加配置文件數據文件的大小。
6.2.5。分岔程序
如果您的程序分叉，該子將繼承所有為父級收集的分析數據。要從小孩中的空配置文件計數器值開始，客戶端請求?CALLGRIND_ZERO_STATS;?可以直接插入到子程序執行的代碼中?fork。
但是，您必須確保輸出文件格式字符串（受控制--callgrind-out-file）確實包含?%p（默認情況下為true）。否則，父母和孩子的輸出將相互覆蓋或混合，這幾乎肯定不是你想要的。
您將能夠通過callgrind_control從父級單獨控制新的孩子。
6.3。Callgrind命令行選項
在下面，選項分為幾類。
一些選項允許指定函數/符號名稱，例如?--dump-before=function或?--fn-skip=function。所有這些選項可以為不同的功能多次指定。此外，函數規范實際上是通過支持使用通配符'*'（零個或多個任意字符）和'？'?（恰好一個任意字符），類似于shell中的文件名稱globbing。這個特性對于C ++來說是非常重要的，因為沒有通配符使用，這個功能必須被全面的指定，包括參數簽名。
6.3.1。轉儲創建選項
這些選項會影響配置文件數據文件的名稱和格式。
--callgrind-out-file=<file>將配置文件數據寫入?file而不是默認的輸出文件?callgrind.out.<pid>。的?%p和%q格式說明可以用來嵌入進程ID和/或名稱的環境變量的內容，由于是用于芯選項的情況下--log-file。當進行多次轉儲時，文件名進一步修改;?見下文。
這指定事件計數應以源行粒度執行。這允許使用調試信息（-g）編譯的源的源注釋。
這指定事件計數應按照指令粒度執行。這允許匯編代碼注釋。目前結果只能由KCachegrind顯示。
此選項會影響配置文件數據的輸出格式。它指定字符串（文件和函數名稱）是否應由數字標識。這縮小了文件，但是使人們更難閱讀（在任何情況下都不推薦）。
此選項會影響配置文件數據的輸出格式。它指定數字位置是否始終被指定為絕對值，或允許與先前數字相對。這縮小了文件大小。
當啟用時，當要生成多個配置文件數據部分時，這些部件將附加到同一個輸出文件。不建議。
6.3.2。活動選項
這些選項指定何時執行與事件計數相關的操作。對于交互式控制使用callgrind_control。
--dump-every-bb=<count> [default: 0, never]每個count基本塊轉儲配置文件數據。只有當運行Valgrind的內部調度程序時才檢查是否需要轉儲。因此，有用的最小設置約為100000.計數是一個64位值，可以使長時間轉儲周期成為可能。
進入時傾倒function。
進入時將所有費用歸零function。
離開時傾倒function。
6.3.3。數據收集選項
這些選項指定何時將事件聚合到事件計數中。另請參閱限制事件收集的范圍。
--instr-atstart=<yes|no> [default: yes]指定您是否希望Callgrind從程序開始啟動仿真和分析。當設置時no，Callgrind將無法收集任何信息，包括通話，但它最多將減緩約4，這是最低Valgrind開銷。儀器可以通過交互方式啟用?callgrind_control -i on。
請注意，生成的調用圖很可能不包含main，但將包含啟用了檢測功能后執行的所有函數。儀器也可以編程啟用/禁用。請參閱callgrind.h您的源代碼中必須使用的宏的Callgrind include文件?。
對于高速緩存模擬，當程序運行后期開啟儀器時，結果將不太準確，因為模擬器在此刻以空白緩存開始。稍后打開事件收集以應對此錯誤。
指定在配置文件運行開始時是否啟用事件收集。
只能看看程序的一些部分，你有兩種可能性：
進入要配置的程序部件之前的零事件計數器，并在離開該程序部件后將事件計數器轉儲到文件中。
根據需要打開/關閉收集狀態，只有在要配置的程序部分內部才能看到事件計數器發生。
如果要配置文件的程序部分被調用多次，可以使用第二個選項。選項1，即創建大量轉儲在這里是不實際的。
可以使用選項在給定功能的進入和退出時切換收集狀態--toggle-collect。如果使用此選項，則開始時應禁用收集狀態。注意--toggle-collect?隱含集的規范?--collect-state=no。
收集狀態也可以通過將客戶端請求?CALLGRIND_TOGGLE_COLLECT ;?插入到所需的代碼位置來切換?。
在入口/出口處切換收藏function。
這指定是否收集（條件）跳轉的信息。如上所述，callgrind_annotate目前無法顯示數據。您必須使用KCachegrind在注釋代碼中獲取跳轉箭頭。
這指定是否應收集系統調用時間的信息。
這指定是否應該收集執行的全局總線事件的數量。事件類型“Ge”用于這些事件。
6.3.4。成本實體分離選項
這些選項指定如何將事件計數歸因于執行上下文。例如，它們指定是否應考慮到導出功能的遞歸級別或調用鏈，以及是否應考慮線程ID。另請參閱避免循環。
--separate-threads=<no|yes> [default: no]此選項指定是否應為每個線程單獨生成配置文件數據。如果是，則文件名稱將附加“-threadID”。
在調用鏈中最多只能分配上下文<callers>函數。請參閱避免循環。
單獨number呼叫者function。請參閱避免循環。
大多數level級別分離函數遞歸。請參閱避免循環。
單獨的number遞歸function。請參閱避免循環。
忽略來自PLT部分的呼叫。
忽略直接遞歸。
忽略來自/來自給定功能的調用。例如，如果您有一個呼叫鏈A> B> C，并且指定功能B被忽略，您將只看到A> C.
這是非常方便的跳過處理回調行為的函數。例如，使用Qt圖形庫中的信號/時隙機制，您只想看到發出信號的功能來調用與該信號相連的插槽。首先，確定真正的呼叫鏈，查看需要跳過的功能，然后使用此選項。
6.3.5。模擬選項
--cache-sim=<yes|no> [default: no]指定是否要進行全緩存模擬。默認情況下，只有指令讀取訪問將被計數（“Ir”）。通過緩存模擬，啟用其他事件計數器：指令讀取（“I1mr”/“ILmr”），數據讀取訪問（“Dr”）和相關高速緩存未命中（“D1mr”/“DLmr”），數據寫入訪問（“Dw”）和相關高速緩存未命中（“D1mw”/“DLmw”）。有關更多信息，請參閱Cachegrind：緩存和分支預測分析器。
指定是否要進行分支預測模擬。啟用其他事件計數器：執行條件分支的數量和相關的預測器丟失（“Bc”/“Bcm”），執行跳轉地址預測器（“Bi”/“Bim”）的間接跳轉和相關未命中。
6.3.6。緩存模擬選項
--simulate-wb=<yes|no> [default: no]指定是否應該模擬回寫行為，允許區分具有和不具有回寫的LL緩存未命中。Cachegrind / Callgrind的高速緩存模型沒有指定寫入與寫回行為，并且這與生成的錯誤計數的數量無關。然而，通過顯式回寫模擬，可以決定錯誤是否觸發不僅加載新的高速緩存行，而且還必須在之前發生臟高速緩存行的回寫。新的臟錯誤事件分別是ILdmr，DLdmr和DLdmw，因為指令讀取，數據讀取和數據寫入。當他們產生兩個內存交易時，他們應該考慮到與正常錯誤相關的雙倍時間估計。
指定是否應添加硬件預取器的仿真，通過比較訪問以分離到每個頁面，能夠檢測第二級緩存中的流訪問。由于模擬不能決定預取的任何時序問題，所以假設任何硬件預取觸發在實際訪問完成之前成功。因此，這通過覆蓋所有可能的流訪問給出了最佳情況。
指定是否應收集高速緩存行的使用。對于每個緩存行，從加載到被驅逐，確定訪問次數以及實際使用的字節數。此行為與觸發加載緩存行的代碼相關。與錯誤計數器相反，它顯示出錯誤緩存行為（即延遲）發生的癥狀的位置，使用計數器嘗試確定原因（即具有不良訪問行為的代碼）。新的計數器的定義方式使得較差的行為導致更高的成本。AcCost1和AcCost2分別是L1和LL緩存的時間局部性差的計數器。這是通過對每個高速緩存行的訪問次數的互逆值進行求和來完成的，乘以1000（僅允許整數成本）。例如，對于具有5個讀取訪問的給定源行，值為5000的AcCost意味著對于每次訪問，新的高速緩存行被加載并且之后被直接驅逐而不進一步訪問。同樣，SpLoss1 / 2分別顯示L1和LL緩存的空間局部性差。它給出了加載到緩存中但從未訪問的字節的空間損失計數。它確定代碼訪問數據的方式，使緩存空間浪費。這暗示了內存中數據結構的布局不佳。假設給定源行的高速緩存行大小為64字節，缺少100個L1，則將觸發向64位字節加載到L1中。如果SpLoss1顯示此行的值為3200，?這意味著一半的加載數據從未被使用，或者使用更好的數據布局，只需要一半的緩存空間。請注意，對于高速緩存行使用計數器，目前無法提供有意義的包容性成本。因此，這些柜臺的包容性成本應該被忽略。
指定級別1指令高速緩存的大小，關聯度和行大小。
指定1級數據緩存的大小，關聯度和行大小。
指定最后一級緩存的大小，關聯性和行大小。
6.4。Callgrind監視器命令
Callgrind工具提供由Valgrind gdbserver?處理的監視器命令（請參閱Valgrind gdbserver的Monitor命令處理）。
-
dump [<dump_hint>]?請求轉儲配置文件數據。
-
zero?請求歸檔配置文件數據計數器。
-
instrumentation [on|off]?請求設置（如果給定參數開/關）或獲取當前的儀器狀態。
-
status?請求打印出一些狀態信息。
6.5。Callgrind特定的客戶端請求
Callgrind提供以下特定的客戶端請求?callgrind.h。請參閱該文件的參數的確切細節。
CALLGRIND_DUMP_STATS在代碼中的指定位置強制生成輪廓轉儲，僅針對當前線程。寫入計數器將被重置為零。
CALLGRIND_DUMP_STATS與之相同，但允許指定一個字符串以能夠區分配置文件轉儲。
將當前線程的配置文件計數器重置為零。
切換收集狀態。這允許忽略關于配置文件計數器的事件。另見選項?--collect-atstart和?--toggle-collect。
如果尚未啟用，請啟動完整的Callgrind儀器。當高速緩存模擬完成時，這將刷新模擬高速緩存，并導致人為高速緩存預熱階段之后的高速緩存未命中，這在現實中不會發生。參見選項--instr-atstart。
如果尚未禁用，請停止完整的Callgrind儀器。這會刷新Valgrinds翻譯緩存，之后不再需要額外的工具：它會以與Nulgrind相同的速度運行，即以最小的減速運行。使用它來加快Callgrind運行的無趣的代碼部分。用于?CALLGRIND_START_INSTRUMENTATION重新啟用儀器。參見選項?--instr-atstart。
6.6。callgrind_annotate命令行選項
-h --help顯示選項摘要。
顯示callgrind_annotate的版本。
僅顯示事件A，B，C的數字。
按事件A，B，C [事件列順序]排序列。
我們感興趣的計數（主要排序事件）的百分比。
注釋包含有助于達到事件計數閾值的函數的所有源文件。
在注釋行之前和之后打印N行上下文。
向函數調用添加子程序成本。
為每個功能打印其呼叫者，被叫功能或兩者。
添加dir到目錄列表以搜索源文件。
6.7。callgrind_control命令行選項
默認情況下，callgrind_control對當前用戶在Callgrind下運行的所有程序起作用。通過提供一個pids或程序名稱作為參數，可以將操作限制為指定的Callgrind運行。默認操作是給出一些關于在Callgrind下運行的應用程序的簡要信息。
-h --help顯示選項的簡短說明，用法和摘要。
顯示callgrind_control的版本。
顯示工作目錄，除了默認給出的簡要信息。
顯示關于活動的Callgrind運行的統計信息。
在活動的Callgrind運行中顯示每個線程的堆棧/后跟蹤。對于堆棧跟蹤中的每個活動功能，還顯示自程序啟動（或最后一次轉儲）以來的調用次數。此選項可以與-e組合以顯示活動功能的包含成本。
顯示事件計數器的當前每線程獨占成本值。如果沒有給出明確的事件名稱，則會顯示在給定Callgrind運行中收集的所有事件類型的數據。否則，僅顯示事件類型A，B，...的數字。如果此選項與-b組合，則還提供每個活動堆棧幀的功能的包含成本。
請求傾倒個人資料信息。可選地，可以指定將描述作為引發觸發轉儲動作的原因的信息的一部分寫入轉儲。這可以用來區分多個轉儲。
將所有事件計數器置零
強制一個Callgrind運行被終止。
打開或關閉儀器儀表模式。如果Callgrind運行禁用了儀器，則不進行任何仿真，也不計算任何事件。這對于跳過不感興趣的程序部件很有用，因為減速比較少（與Valgrind工具“none”一樣）。另請參閱Callgrind選項--instr-atstart。
指定由callgrind_control使用的vgdb前綴。callgrind_control內部使用vgdb來查找和控制活動的Callgrind運行。如果該--vgdb-prefix選項用于啟動valgrind，則必須向callgrind_control提供相同的選項。
總結
以上是生活随笔為你收集整理的Callgrind：调用图生成缓存和分支预测分析器的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Flume1.7.0的安装与使用
- 下一篇： 为何被主流抛弃-江西IDC机房价格为何居