總結：windows下效能分析以及最佳化報告

標籤：bsp   pen   har   open   遇到   個數   100%   ati   圖片   

　　

　　　　效能分析以及最佳化

　    使用的是vs2017內建的效能分析工具。

　　主要分析了遇到的效能瓶頸，以及想到的最佳化方法，有的驗證了，有的沒有來得及。

　　首先看整體用時以及cpu佔有率。

　　最終在我的裝置上(I5-5200U 三星860EVO固態)已耗用時間約為27.3S。期間cpu佔有率比較穩定.

　　前0.5秒cpu佔用率低，大概是因為這段時間是剛開始讀取檔案，cpu並沒有處理任務，後來便進入一邊讀取一遍計算的狀態，cpu佔有率就上來了，大概25%，但是還是不高。

　　而且在這裡我遇到一個十分奇怪的現象

 

　　　　　　　　　　

　　直到代碼運行結束，ReadByChar的佔有率一直居高不下，佔有一直接近100%，這就有點難以理解，講道理最後cpu做的是事情應該是遍曆1600多萬個單詞尋找最大值，並且感覺應該會花許多時間，也就是說尋找前十的top（）函數應該在最後的的幾秒佔用率極高，但是沒有發現這個現象，感覺應該還是這個效能分析結果自己理解有偏差把。

　　我們先看看效能瓶頸：

 

 

　　ReadByChar是我寫的字元讀入，以及單詞判定邏輯實現的函數，並且其調用了許多其他函數，所以它飄紅是意料之中的。

　　進入函數，首先佔用最高的是

　　　　　　

 

　　openbychar是一個fstream的執行個體對象，get（）為擷取字元的方法，雖然條語句花費了許多時間，但這是必須的，處理思路就是要求必須一個一個的處理，基本沒有最佳化餘地，但是假如建立對象，而是使用c語言檔案讀取的方法，因為不需要建立對象調用方法，一定是可以快的，但是最後時間沒來的及，就沒有改。

　　從這裡我們也可以發現，檔案讀取（IO）是一個瓶頸，我當時有思考大幅度改善這個問題，不太確定多線程能否改善這個問題，因為在這個程式中應該是不處理完當前字元是不會讀取下一個的，但是多線程後，可以將檔案分成多份分別處理，再綜合起來，因為從代碼熱行看，雜湊表訪問是非常快的，幾乎沒有耗費時間，這樣最後結果整合應該也花費不了多少時間，但是無奈時間倉促，而且ddl前出現了bug，沒有來得及驗證，最近有時間一定試一下。

 

　　　word[sword]與wordend[sword]尋找都用時較多，但這個也是沒有辦法的，這部分花費尋找的時間也是必須的，而且選取hash已經是想到的最優的方法，再想最佳化，就得針對資料特徵進行分析，更改預設的hash函數 ，讓單詞盡量減少衝突，這花費時間太多了，也不一定能比預設的hash快多少，所以就沒搞。

　　

 

　　這個地方是我之前說過的唯一一處算是做出有卓越成效的最佳化，首先這兩句是完成片語拼接，每判定成功就要執行一次，從最後單詞結果看是執行了1600多萬次，我之前圖簡單，直接寫的是sphrase=sphrase+ " ”+sword，總時間佔有率高達10%，但是這樣寫運算式右側會先建立一個對象儲存結果，然後再賦給sphrase，比較複雜，想變快應該調用string內建的拼接方法，我更改之後，佔有率直接降到1%以下。

　　其餘的代碼在整個代碼運行過程中幾乎不佔多少時間。

　　但是假如真的是追求極致的話，感覺有幾個細節還是可以修改下的。

　　1

　　一些經常調用的函數中的變數對象可以用static修飾為靜態，這樣就不用每次調用時候都重新建立對象了，有這個特點的是getmax（），getmin（）函數，這兩個在輸出結果檔案，以及尋找前十中會被多次用到，但是對於一個30s的任務，這樣的最佳化根本沒有什麼作用。

　　

 

　　2

           尋找前十的方法，我是一次遍曆，遍曆過程中儲存一個數組，每次替代其中的最小值，這樣每讀一個詞，就要在10個詞中尋找最小值，這個從分析看並不是效能瓶頸，因為10個實在太少了，但是假如尋找最小的10000個，100000個肯定就不能這麼寫了，我們雖然還是用一次遍曆的方法，但是此時應該維護的是一個10000大小的最小堆。

　　以上就是效能分析以及最佳化思路

　　

　　

　　

 

總結：windows下效能分析以及最佳化報告