性能分析以及優化

　 使用的是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下性能分析以及優化報告