性能調優難題
下圖為vs2010采用CPU采樣的性能分析報告（release版本），其中紅線部分相當困惑，為什么開銷這么大？
release的反匯編如下：
debug的反匯編如下：
從反匯編來看，release將cmp優化成test。
首頁就是profile工具的分析結果
很不幸，不是
反匯編出來只是將jne改成了je
您回錯帖了吧！
所以這個肯定是假馬甲嘛。
道理沒錯，不是主要的開銷，但是不明不白的出現這么一個不合情理的開銷，心里頭不舒服。
6.1%的這個差不多到極限了，對象的數目太多了，上百萬。
改用boost::unordered_map效率稍微好點，不過會增clean線程和鎖的開銷，總體差不多。
39.1%的是后面的主處理流程，正在進一步優化。
test & jne/je 不可能會帶來這么大的開銷，可能這個問題不在於 line 26，而在於 line 25. 你在 line 25 后面弄個簡單的語句試試看，比如一個簡單的加法運算，有可能這個簡單的加法會讓我們吃一驚。
這個可能在點子上了，我也懷疑是數組取值的問題，這個數組有1M，參看下面一個64k的數組取值：
紅色部分效率不高，之前是這么寫的：
那個0.6%的CPU占用就出在if (cell_id_array_[bvci] == 0)這一行。
是否可能頁面錯誤導致？這一塊我不是很熟悉，但是我將windows的虛擬內存完全禁用后，程序的頁面錯誤變化不大。
是否可能CPU cache命中率太低導致？對於這種大數組，不可能全部讀進cache。
我對於技術的態度是，知其然，更要知其所以然。雖然我的行業是移動通信，但是對於C++開發的態度是一致的。
測了很多次了，差不多沒有什么變化。
如果你監測到了頁面錯誤較多，說明內存吃緊，已經發生了較多的磁盤交換內存頁面了，那會有影響，用 profiler 監測的時候，profiler 和你的程序是一起跑的，profiler要做更多的工作，消耗更多的內存，這也會導致你的程序內存緊張。
CPU cache命中率對單條語句的影響不會這么誇張，這么大的影響更有可能是背后發生了磁盤操作。如果可能的話，修改一下程序，改成直接的物理內存（不用malloc/new）試試看。
“如果你監測到了頁面錯誤較多，說明內存吃緊”，這句是錯誤的。
這個圖還是在將windows虛擬內存完全禁用后截取的：
以下問題搞不明白：
將windows虛擬內存完全禁用后，內存會交換到什么地方？
如果沒有磁盤分頁文件可以交換，為什么還會出現page fault？
忘了說配置了：
以下假設所說的頁面錯誤指 Page Fault.
如果已經將虛擬內存完全禁用了，那應該不存在內存和頁面文件的交換。這時出現 page fault 可以忽略，它仍然是從物理內存讀寫，而且我們也沒有確定是在那個時間點發生了 page fault。
你的 i7 有6M的cache，程序應該還是蠻大機會占用一點的。如果是因為數組太大導致cache的切換，而導致CPU消耗偏多的話，也是有可能的，0.8/0.1 ＝ 8，和內存/cache速率比也相近。進行每條語句的消耗時間探測的話，每條語句之間都要有探針代碼，實際在CPU里面運行的情況要比匯編代碼所顯示的復雜。
雖然未能肯定是何原因，但是和內存存取緊密相關這一點是最可能的。或者試下改變 line 25 的數組的大小，從1k到1M不等，對比看看。
之前的兩個問題已經弄明白了，page fault 分為 hard和soft兩種。
首頁的問題我現在更傾向於CPU采樣的不准確性導致的。
在整個測試過程中除了帖子中列出的，實際上還有一些不太理解的較大的開銷，比如：
update_user_ip_kpi函數邏輯也很簡單，一些比較和加法語句而已，但是與主處理邏輯相比開銷是其差不多30%。
使用檢測方式重新測量的結果如下：
兩者的比值就只有不到7%了。
release的反匯編如下：
debug的反匯編如下：
從反匯編來看，release將cmp優化成test。
26 个解决方案
#1
慢的不是cmp是jne
#2
??
第33行代碼同樣有jne指令，並且還是cmp而不是test，為何這兩行（26、33）的開銷對比如此大（這兩行執行的次數完全一樣多）
第33行代碼同樣有jne指令，並且還是cmp而不是test，為何這兩行（26、33）的開銷對比如此大（這兩行執行的次數完全一樣多）
#3
Sorry，首頁的反匯編搞錯類了，不過都差不多，還是以上問題，對比首頁33行的反匯編和26行的反匯編，為什么這兩行代碼的執行效率差別這么大。
一下重貼26行的反匯編
一下重貼26行的反匯編
#4
在用人腦判斷效率瓶頸之前，請先用Profiler工具。
#5
首頁就是profile工具的分析結果
#6
if的命中率的問題吧
#7
用C語言1000行源碼能完成的工作千萬不要用C++重寫！
#8
很不幸，不是
反匯編出來只是將jne改成了je
#9
您回錯帖了吧！
#10
所以這個肯定是假馬甲嘛。
#11
這個差別貌似可以忽略不計。
那個1.1%就算降到0.1%也沒有意義。
那個1.1%就算降到0.1%也沒有意義。
#12
我只注意到樓主提供圖片中的
6.1% 32 ……
39.1% 40 ……
6.1% 32 ……
39.1% 40 ……
#13
道理沒錯，不是主要的開銷，但是不明不白的出現這么一個不合情理的開銷，心里頭不舒服。
#14
6.1%的這個差不多到極限了，對象的數目太多了，上百萬。
改用boost::unordered_map效率稍微好點，不過會增clean線程和鎖的開銷，總體差不多。
39.1%的是后面的主處理流程，正在進一步優化。
#15
test & jne/je 不可能會帶來這么大的開銷，可能這個問題不在於 line 26，而在於 line 25. 你在 line 25 后面弄個簡單的語句試試看，比如一個簡單的加法運算，有可能這個簡單的加法會讓我們吃一驚。
#16
一個簡單語句被調用100000次也會比復雜指令調用1次耗時
#17
單純看匯編不會這么慢，是不是后面的跳轉遇到上下文切換了。Lz多測幾次，取個平均看看
#18
擒賊先擒王！
#19
這個可能在點子上了，我也懷疑是數組取值的問題，這個數組有1M，參看下面一個64k的數組取值：
紅色部分效率不高，之前是這么寫的：
if (cell_id_array_[bvci] == 0) {
helper_->update_bssgp_dl_unitdata__stats(BSSGP_DL_UNITDATA_CELL_UNFOUND);
return;
}
bssgp_unitdata_head.cell_id = cell_id_array_[bvci];
那個0.6%的CPU占用就出在if (cell_id_array_[bvci] == 0)這一行。
是否可能頁面錯誤導致？這一塊我不是很熟悉，但是我將windows的虛擬內存完全禁用后，程序的頁面錯誤變化不大。
是否可能CPU cache命中率太低導致？對於這種大數組，不可能全部讀進cache。
#20
我對於技術的態度是，知其然，更要知其所以然。雖然我的行業是移動通信，但是對於C++開發的態度是一致的。
#21
測了很多次了，差不多沒有什么變化。
#22
如果你監測到了頁面錯誤較多，說明內存吃緊，已經發生了較多的磁盤交換內存頁面了，那會有影響，用 profiler 監測的時候，profiler 和你的程序是一起跑的，profiler要做更多的工作，消耗更多的內存，這也會導致你的程序內存緊張。
CPU cache命中率對單條語句的影響不會這么誇張，這么大的影響更有可能是背后發生了磁盤操作。如果可能的話，修改一下程序，改成直接的物理內存（不用malloc/new）試試看。
#23
“如果你監測到了頁面錯誤較多，說明內存吃緊”，這句是錯誤的。
這個圖還是在將windows虛擬內存完全禁用后截取的：
以下問題搞不明白：
將windows虛擬內存完全禁用后，內存會交換到什么地方？
如果沒有磁盤分頁文件可以交換，為什么還會出現page fault？
#24
忘了說配置了：
#25
以下假設所說的頁面錯誤指 Page Fault.
如果已經將虛擬內存完全禁用了，那應該不存在內存和頁面文件的交換。這時出現 page fault 可以忽略，它仍然是從物理內存讀寫，而且我們也沒有確定是在那個時間點發生了 page fault。
你的 i7 有6M的cache，程序應該還是蠻大機會占用一點的。如果是因為數組太大導致cache的切換，而導致CPU消耗偏多的話，也是有可能的，0.8/0.1 ＝ 8，和內存/cache速率比也相近。進行每條語句的消耗時間探測的話，每條語句之間都要有探針代碼，實際在CPU里面運行的情況要比匯編代碼所顯示的復雜。
雖然未能肯定是何原因，但是和內存存取緊密相關這一點是最可能的。或者試下改變 line 25 的數組的大小，從1k到1M不等，對比看看。
#26
之前的兩個問題已經弄明白了，page fault 分為 hard和soft兩種。
首頁的問題我現在更傾向於CPU采樣的不准確性導致的。
在整個測試過程中除了帖子中列出的，實際上還有一些不太理解的較大的開銷，比如：
update_user_ip_kpi函數邏輯也很簡單，一些比較和加法語句而已，但是與主處理邏輯相比開銷是其差不多30%。
使用檢測方式重新測量的結果如下：
兩者的比值就只有不到7%了。
注意！
本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。