C++程序性能分析

最近要對推送程序進行性能優化，找出程序的hot spots，程序是用VS2005，C++寫的，因此直接使用VS2005自帶的性能分析工具對程序作了一次profiling。

準備工做

使用VS2005打開工程，在菜單「工具」下面有個「性能工具」的選項，點擊右邊的「性能嚮導」就能夠開始新建一個性能測試項了。 如： 若是點擊菜單沒有看到上圖的「性能工具」選項，說明安裝時候沒有選擇安裝測試工具，請到「控制面板」->「添加刪除程序」裏面進入VS2005的維護模式，將「team development和team test工具」選上。如圖： 從新安裝VS2005，重啓VS2005便可。

測試模式

有兩種：採樣和檢測。

對於一個Profiler來講，給程序帶來負擔（overhead）是難以免的。通常來講，Profiler都會提供多種探測方式，例如採樣（Sampling）或是追蹤（Tracing）。「採樣」通常都是定時打點，看看程序每一個線程當前落在哪一個方法裏，當前的調用堆棧是什麼，以此發現程序熱點，「追蹤」則每每會記錄方法進入和退出的時間，因此顯然前者的負擔要小事後者。趙人希的微信

「檢測」應該就是趙人希所說的「追蹤」方式。本次測試開始用「採樣」方式，可是運行時報錯，因此最終使用了「檢測」方式。

測試過程

經過嚮導很是簡單的創建了測試項以後就會出現「性能資源管理器」。設好參數，點擊開始。程序就跑起來了。這跟普通的調試程序編譯運行沒啥兩樣。在此過程當中，測試程序不斷的給被測程序發請求，增長壓力，以便較好的模擬程序真實的使用場景。壓了10多分鐘吧，估計差很少了，退出被測程序，VS就開始生成性能分析報告，此過程甚是漫長，估計快弄了20分鐘左右。看來咱們的推送程序仍是作了很多工做。接下去就能夠看到分析結果了。

測試結果

對於測試結果的查看能夠參考MSDN上的介紹。 具體到本次測試程序，結果以下： 從最多調用次數看：因爲函數名都是C++連接以後的名字，函數名部分被改寫沒法識別，猜想前兩個是基本的stl的字符串比較和賦值等操做，第三個是memset，調用次數最多但不必定是最耗時的瓶頸。 耗時最長分別爲wait（ACE線程等待函數）、伊諾收包的回調函數OnRecvRequest和伊諾的定時器OnTimer函數。估計wait函數是阻塞的，一直都在wait不耗CPU？反正這個目前也不在個人控制範圍以內，先無論；伊諾的OnRecvRequest和OnTimer函數是直接調用的TCClient.dll。無代碼也不能控制。囧oz。 接下去的幾個tab主要展現的幾列爲：總調用次數、函數自己調用所用時間（不包括函數中調用其餘函數的時間。只是自己的耗時）簡稱「淨時間」、略、函數調用所用的時間（包括函數調用中調用其餘函數的時間）簡稱「總時間」、略 經過淨時間和總時間的關係、函數調用樹的關係能夠找到程序的熱點——哪一個函數比較耗時。 首先，耗時的函數其總時間與淨時間之差應該很小，一眼看去應該是基本相等的。 其次，對總時間排序，經過函數調用關係樹，逐級查看，最終找到合適粒度的耗時函數。 memset的調用最多。與代碼中把C++當C用、滿眼所見都是memset十分吻合。但也能夠看出memset雖然用的不少，但因爲其效率很高，總的耗費時間並不高。

ACE隊裏的dequeue函數在隊列爲空時會阻塞。經過函數調用關係tree發現最終調用花費的時間都用在了wait函數上。 以Process函數爲例，逐級查看下去，最耗時的操做在函數MsgReqProc1中，其最耗時的操做均爲數據庫操做。如圖

經過對總時間高的多個函數的追蹤，綜合查看能夠發現，此程序最耗時的操做均是對數據庫上的操做。後面對數據庫的分析也印證了此結論。

從上面圖中能夠看出，全部涉及到數據庫操做的耗時都是實打實的。並且增刪查改的操做都是耗時的大戶。能少用盡可能少用。並且ODBCDB.dll的總的淨耗時比PubServ.dll的耗時高不少。也說明了其消耗了大量的時間。

優化方法

1. 減小沒必要要的數據庫操做。
2. 對數據庫採用異步、批量的操做方式，減小等待和阻塞。
3. 多使用緩存。
4. 優化數據庫性能。如採用內存數據庫、優化存儲過程性能等。