在VC2010上利用運行時程序性能分析工具對HM編碼器進行性能分析，獲取代碼的關鍵路徑，爲後面對算法和代碼進行優化提供參考。
參考程序版本爲HM-10.1-dev，分析工具爲VC2010集成代碼性能分析工具，測試序列爲BQSquare_416x240_60，配置文件爲encoder_intra_main.cfg和BQSquare.cfg。
有人反映VC跑測試軟件編碼器非常慢，需要幾個小時，我測試了一下是這樣的，我使用上面的測試序列和配置文件，運行編碼器耗時6236s。電腦配置爲Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz 八核處理器，3.39GHz, 3.40GB內存，WindowsXPSP3系統。這麼小的一個視頻編碼耗時1.8小時，也太慢了，編碼時電腦CUP佔用率13%，說明代碼有很多的優化潛力。後來看了下VC設置看能不能設置優化的，然後看到方案默認爲Debug模式，其他優化選項好像是正常的，就將Debug改爲Release模式，在編譯運行上面同樣的序列和配置，耗時630s，電腦CPU佔用率還是13%，速度差不多快了10倍，確實是減少時間的方法，應該還是可以優化的。
下面繼續VC2010進行程序性能分析。
電腦配置：
參數配置：
-c encoder_intra_main.cfg -c BQSquare.cfg 612x240x60
運行編碼器：
VC2010中Debug模式運行編碼器，612x240x60序列，耗時6226s
VC2010中Release模式運行編碼器，612x240x60序列，耗時623s，相差10倍了
兩種模式下CPU佔用率差不多
啓動VC性能分析工具進行HM性能分析：
關鍵路徑：
TAppEncoder.exe 187,486
main: 187,034
-- TAppEncTop::encode() 187,034
--TEncGOP::compressGOP() 186,972
--TEncSlice::compressSlice() 185,016
--TEncCu::xCheckRDCostIntra() 18,236
--TEncSearch::estIntraPredChromaQT 2,062
--TEncSearch::estIntraPredQT 15,894
--TEncCu::xCompressCU() 165,893
--TEncCu::xCheckRDCostIntra() 109,110
--TEncSearch::estIntraPredChromaQT 11,853
--TEncSearch::extIntraPredQT() 96,206
--TEncSearch::xRecurIntraCodingQT() 75,052
--TComPrediction::preIntraLumaAng() 5,909
--TComRdCost::calcHAD() 5,276
換一個配置文件測試：
-c encoder_lowdelay_main.cfg -c BQSquare.cfg 612x240x60
使用這個配置文件時，分析得到的關鍵路徑與之前的路徑差別較大，但是對比函數調用關係樹的話還是差不多的。
主要消耗還是compressCU函數
編碼器測試：
使用編碼器對-c encoder_intra_main.cfg -c BQSquare.cfg 612x240x60序列編碼文件解碼：
解碼總共耗時8s，CPU佔用率13%
解碼速度還是可以的，但這個YUV圖像大小很小，需要測試更大尺寸的序列，同時使用更高性能的配置參數進行編碼和解碼測試。
來對比一下編解碼圖像質量
原始YUV文件第一幀：
編解碼後第一幀：
整體上和原始圖像差不多，注意地板的紋理，編解碼後地板在亮區的紋理已經沒有了，在暗區如左下角太陽傘下紋理還可以看到。
原始YUV序列第500幀：
編解碼後YUV序列第500幀：
可以看出陽臺瓷磚紋理、雨傘紋理、鐵柵欄紋理和水面紋理都有了不同程度的模糊。