[筆記] performance profiler: callgrind

Linux 上常聽到的 run time profiler 應該就是 gprof 了，不過進公司後才知道原來 valgrind 自己也有一套 profiler 叫 callgrind，精準度的話目前還不清楚跟 gprof 比起來誰比較高，但是大致用起來我覺得比 gprof 好上手，原因的話在於它有 GUI 可以直接看 call graph，方便很多。

valgrind 雖然其實是好幾套軟體的集合體，不過我完全沒注意到它內部有個 callgrind 是用來協助分析 performance 的，使用方法的話像這樣

$ valgrind --tool=callgrind [program to be executed] [program option]

基本上就像一般使用 valgrind 那樣，只是加上 --tool 去指定要跑的是 callgrind 而不是 memcheck。可以下的參數也不太一樣了，我自己用的是這幾項：

• --callgrind-out-file=<log file name>
• --dump-instr=yes
• --trace-jump=yes

--dump-instr 根據 manual 來看主要是為了 GUI 介面用的，他可以把每一行要執行多少 event (還不清楚是不是就是 assembly code 的數量) 都顯示出來以供參考

--trace-jump 是 GUI 那套軟體推薦加上去的，不過我查 manual 沒看到，不曉得是怎麼回事 @@ 不過貌似也是輔助用來分析 call graph 跟 instruction count 用的

至於 callgrind 的資料有兩種方法可以看，但是絕對不是直接把 profiling 後的資料用編輯器開來看，直接看是看不懂的 XD

1. 用 callgrind_annotate：這是文字介面
2. 用 kcachergrind：這是 GUI 介面

文字介面的話如果直接跑可能看不出啥鬼，雖然它會把每個 function 各自執行了多少指令排序後印出來，但是要抓出問題所在其實有點難，因為經過排序後你不一定有辦法知道問題點是程式中的哪一段，所以我自己是會加上別的參數輔助：

• --auto=yes

這個參數它會把 source code 也放進來，然後直接在旁邊標記每一行各自執行了多少指令，特別是如果有預期外的指令呼叫時也可以在這時候很清楚的看到。

至於 GUI 介面的話，kcachegrind 打開 callgrind 生成的檔案後資料就有一大堆了，包含 call graph, caller graph, callee graph, 跟 callgrind_control 一樣的 source code 相關資訊 ... 等等；執行的指令數量預設也會轉化成百分比的形式顯示，會比直接看數字更清楚；同時百分比的資訊還會進一步地轉化成方塊的大小，所以當你看到某個該死的傢伙怎麼面積那麼大時就知道誰是元兇了，方便很多。

不過 callgrind 還有另一套輔助軟體叫 callgrind-control，說是可以讓你在 callgrind 執行過程中直接操作程式的執行狀況輔助分析，不過還沒試用成功，所以以後再說。