性能調優難題


下圖為vs2010采用CPU采樣的性能分析報告(release版本),其中紅線部分相當困惑,為什么開銷這么大?



release的反匯編如下:



debug的反匯編如下:


從反匯編來看,release將cmp優化成test。

26 个解决方案

#1


慢的不是cmp是jne

#2


??
第33行代碼同樣有jne指令,並且還是cmp而不是test,為何這兩行(26、33)的開銷對比如此大(這兩行執行的次數完全一樣多)

#3


Sorry,首頁的反匯編搞錯類了,不過都差不多,還是以上問題,對比首頁33行的反匯編和26行的反匯編,為什么這兩行代碼的執行效率差別這么大。
一下重貼26行的反匯編


#4


在用人腦判斷效率瓶頸之前,請先用Profiler工具。

#5


引用 4 樓 zhao4zhong1 的回復:
在用人腦判斷效率瓶頸之前,請先用Profiler工具。


首頁就是profile工具的分析結果

#6


if的命中率的問題吧

#7


用C語言1000行源碼能完成的工作千萬不要用C++重寫!

#8


引用 6 樓 zilaishuichina 的回復:
if的命中率的問題吧


很不幸,不是


反匯編出來只是將jne改成了je

#9


引用 7 樓 zhao4zhong2 的回復:
用C語言1000行源碼能完成的工作千萬不要用C++重寫!


您回錯帖了吧!

#10


引用 9 樓 moolleychean 的回復:
引用 7 樓 zhao4zhong2 的回復:用C語言1000行源碼能完成的工作千萬不要用C++重寫!

您回錯帖了吧!

所以這個肯定是假馬甲嘛。

#11


這個差別貌似可以忽略不計。
那個1.1%就算降到0.1%也沒有意義。

#12


我只注意到樓主提供圖片中的
 6.1% 32 ……
39.1% 40 ……

#13


引用 11 樓 raison_x 的回復:
這個差別貌似可以忽略不計。
那個1.1%就算降到0.1%也沒有意義。


道理沒錯,不是主要的開銷,但是不明不白的出現這么一個不合情理的開銷,心里頭不舒服。

#14


引用 12 樓 zhao4zhong1 的回復:
我只注意到樓主提供圖片中的
 6.1% 32 ……
39.1% 40 ……


6.1%的這個差不多到極限了,對象的數目太多了,上百萬。
改用boost::unordered_map效率稍微好點,不過會增clean線程和鎖的開銷,總體差不多。

39.1%的是后面的主處理流程,正在進一步優化。

#15


引用 13 樓 moolleychean 的回復:
引用 11 樓 raison_x 的回復:這個差別貌似可以忽略不計。
那個1.1%就算降到0.1%也沒有意義。

道理沒錯,不是主要的開銷,但是不明不白的出現這么一個不合情理的開銷,心里頭不舒服。


test & jne/je 不可能會帶來這么大的開銷,可能這個問題不在於 line 26,而在於 line 25. 你在 line 25 后面弄個簡單的語句試試看,比如一個簡單的加法運算,有可能這個簡單的加法會讓我們吃一驚。

#16


一個簡單語句被調用100000次也會比復雜指令調用1次耗時

#17


單純看匯編不會這么慢,是不是后面的跳轉遇到上下文切換了。Lz多測幾次,取個平均看看

#18


擒賊先擒王!

#19


引用 15 樓 raison_x 的回復:
引用 13 樓 moolleychean 的回復:引用 11 樓 raison_x 的回復:這個差別貌似可以忽略不計。
那個1.1%就算降到0.1%也沒有意義。

道理沒錯,不是主要的開銷,但是不明不白的出現這么一個不合情理的開銷,心里頭不舒服。

test & jne/je 不可能會帶來這么大的開銷,可能這個問題不在於 line 26,而在於 line……


這個可能在點子上了,我也懷疑是數組取值的問題,這個數組有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


引用 18 樓 zhao4zhong1 的回復:
擒賊先擒王!


我對於技術的態度是,知其然,更要知其所以然。雖然我的行業是移動通信,但是對於C++開發的態度是一致的。

#21


引用 17 樓 givemekey 的回復:
單純看匯編不會這么慢,是不是后面的跳轉遇到上下文切換了。Lz多測幾次,取個平均看看


測了很多次了,差不多沒有什么變化。

#22


引用
引用 15 樓 raison_x 的回復:
    引用 13 樓 moolleychean 的回復:引用 11 樓 raison_x 的回復:這個差別貌似可以忽略不計。
    那個1.1%就算降到0.1%也沒有意義。
    道理沒錯,不是主要的開銷,但是不明不白的出現這么一個不合情理的開銷,心里頭不舒服。
    test & jne/je 不可能會帶來這么大的開銷,可能這個問題不在於 line 26,而在於 line……
這個可能在點子上了,我也懷疑是數組取值的問題,這個數組有1M,參看下面一個64k的數組取值:
......
是否可能頁面錯誤導致?這一塊我不是很熟悉,但是我將windows的虛擬內存完全禁用后,程序的頁面錯誤變化不大。
是否可能CPU cache命中率太低導致?對於這種大數組,不可能全部讀進cache。

如果你監測到了頁面錯誤較多,說明內存吃緊,已經發生了較多的磁盤交換內存頁面了,那會有影響,用 profiler 監測的時候,profiler 和你的程序是一起跑的,profiler要做更多的工作,消耗更多的內存,這也會導致你的程序內存緊張。
CPU cache命中率對單條語句的影響不會這么誇張,這么大的影響更有可能是背后發生了磁盤操作。如果可能的話,修改一下程序,改成直接的物理內存(不用malloc/new)試試看。

#23


引用 22 樓 raison_x 的回復:
引用引用 15 樓 raison_x 的回復:
    引用 13 樓 moolleychean 的回復:引用 11 樓 raison_x 的回復:這個差別貌似可以忽略不計。
    那個1.1%就算降到0.1%也沒有意義。
    道理沒錯,不是主要的開銷,但是不明不白的出現這么一個不合情理的開銷,心里頭不舒服。
    test & jne/je 不可……



“如果你監測到了頁面錯誤較多,說明內存吃緊”,這句是錯誤的。
這個圖還是在將windows虛擬內存完全禁用后截取的:

以下問題搞不明白:
將windows虛擬內存完全禁用后,內存會交換到什么地方?
如果沒有磁盤分頁文件可以交換,為什么還會出現page fault?

#24


引用 23 樓 moolleychean 的回復:
引用 22 樓 raison_x 的回復:引用引用 15 樓 raison_x 的回復:
    引用 13 樓 moolleychean 的回復:引用 11 樓 raison_x 的回復:這個差別貌似可以忽略不計。
    那個1.1%就算降到0.1%也沒有意義。
    道理沒錯,不是主要的開銷,但是不明不白的出現這么一個不合情理的開銷,心里頭不舒服。
   ……


忘了說配置了:


#25


引用
引用 22 樓 raison_x 的回復:

    引用引用 15 樓 raison_x 的回復:
        引用 13 樓 moolleychean 的回復:引用 11 樓 raison_x 的回復:這個差別貌似可以忽略不計。
        那個1.1%就算降到0.1%也沒有意義。
        道理沒錯,不是主要的開銷,但是不明不白的出現這么一個不合情理的開銷,心里頭不舒服。
        test & jne/je 不可……
“如果你監測到了頁面錯誤較多,說明內存吃緊”,這句是錯誤的。
以下問題搞不明白:
將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不等,對比看看。

#26


引用 25 樓 raison_x 的回復:
引用引用 22 樓 raison_x 的回復:

    引用引用 15 樓 raison_x 的回復:
        引用 13 樓 moolleychean 的回復:引用 11 樓 raison_x 的回復:這個差別貌似可以忽略不計。
        那個1.1%就算降到0.1%也沒有意義。
        道理沒錯,不是主要的開銷,但是不明不白的出現這么……


之前的兩個問題已經弄明白了,page fault 分為 hard和soft兩種。

首頁的問題我現在更傾向於CPU采樣的不准確性導致的。
在整個測試過程中除了帖子中列出的,實際上還有一些不太理解的較大的開銷,比如:

update_user_ip_kpi函數邏輯也很簡單,一些比較和加法語句而已,但是與主處理邏輯相比開銷是其差不多30%。
使用檢測方式重新測量的結果如下:

兩者的比值就只有不到7%了。

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



Android性能調優----1 Spark性能調優(一) javascript的性能調優 性能調優攻略(3) 性能調優綜述 關於iOS性能調優 性能調優概述 EBS的性能調優 性能調優大綱 性能調優-思路
 
粤ICP备14056181号  © 2014-2020 ITdaan.com