• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 132  文章 - 51  trackbacks - 0
            <2012年7月>
            24252627282930
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            常用鏈接

            留言簿(7)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            cocos2d-x

            OGRE

            OPenGL

            搜索

            •  

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            游戲中接受到的消息那叫一個(gè)多如牛毛啊,這就涉及到switch case接受還是if else接受的效率問題
            有人說這是個(gè)小問題,哈哈 精益求精嗎

            看到了一篇兩者效率比較的文章:


            switch...case與if...else的根本區(qū)別在于,switch...case會(huì)生成一個(gè)跳轉(zhuǎn)表來指示實(shí)際的case分支的地址,而這個(gè)跳轉(zhuǎn)表的索引號(hào)與switch變量的值是相等的。從而,switch...case不用像if...else那樣遍歷條件分支直到命中條件,而只需訪問對(duì)應(yīng)索引號(hào)的表項(xiàng)從而到達(dá)定位分支的目的。

            具體地說,switch...case會(huì)生成一份大小(表項(xiàng)數(shù))為最大case常量+1的跳表,程序首先判斷switch變量是否大于最大case常量,若大于,則跳到default分支處理;否則取得索引號(hào)為switch變量大小的跳表項(xiàng)的地址(即跳表的起始地址+表項(xiàng)大小*索引號(hào)),程序接著跳到此地址執(zhí)行,到此完成了分支的跳轉(zhuǎn)。如下代碼(gcc編譯,不開優(yōu)化):

            int main()
            {
                int j = 0;
                int i = 1;

                switch (i)
                {
                    case 1:
                        j = 11;
                        break;
                    case 2:
                        j = 22;
                        break;
                    case 3:
                        j = 33;
                        break;
                    case 4:
                        j = 44;
                        break;
                    case 10:
                        j = 10;
                
                    default:
                        j = 88;
                        break;
                }

                return 0;
            }

            這是編譯后的部分匯編碼:

                .file    "test.c"
                .text
            .globl main
                .type    main, @function
            main:
                leal    4(%esp), %ecx
                andl    $-16, %esp
                pushl    -4(%ecx)
                pushl    %ebp
                movl    %esp, %ebp
                pushl    %ecx
                subl    $16, %esp
                movl    $0, -8(%ebp)
                movl    $1, -12(%ebp)
                cmpl    $10, -12(%ebp)
                ja    .L2
                movl    -12(%ebp), %eax
                sall    $2, %eax
                movl    .L8(%eax), %eax
                jmp    *%eax
                .section    .rodata
                .align 4
                .align 4
            .L8:
                .long    .L2
                .long    .L3
                .long    .L4
                .long    .L5
                .long    .L6
                .long    .L2
                .long    .L2
                .long    .L2
                .long    .L2
                .long    .L2
                .long    .L7
                .text
            .L3:
                movl    $11, -8(%ebp)
                jmp    .L9
            .L4:
                movl    $22, -8(%ebp)
                jmp    .L9
            .L5:
                movl    $33, -8(%ebp)
                jmp    .L9
            .L6:
                movl    $44, -8(%ebp)
                jmp    .L9
            .L7:
                movl    $10, -8(%ebp)
            .L2:
                movl    $88, -8(%ebp)
            .L9:
                movl    $0, %eax
                addl    $16, %esp
                popl    %ecx
                popl    %ebp
                leal    -4(%ecx), %esp
                ret

            可以打個(gè)比方,switch...case訪問條件分支的方式像數(shù)組一樣,是隨機(jī)訪問;而if...else是順序訪問。

            他們各自的特點(diǎn):

            1、 總體上說,switch...case 效率要高于同樣條件下的if...else,特別是當(dāng)條件分支較多時(shí)。

            2、switch...case占用較多的代碼空間,因?yàn)樗商恚貏e是當(dāng)case常量分布范圍很大但實(shí)際有效值又比較少的情況,switch...case的空間利用率將變得很低。例如上面的代碼,如果把case 10改成case 100,則會(huì)生成101個(gè)表項(xiàng),而大部分表項(xiàng)是指向同一分支(default分支)。switch...case是在以空間換時(shí)間。

            3、switch...case只能處理case為常量的情況,對(duì)非常量的情況是無能為力的。例如 if (a > 1 && a < 100),是無法使用switch...case來處理的。

            ***注意:如果把例子中的case分支減少一個(gè),則生成的匯編碼與if...else差別不大,此時(shí)不會(huì)生成跳表項(xiàng),可見對(duì)于分支較少的情況,編譯器會(huì)做特殊處理。

            原文地址:http://blog.csdn.net/kevinyujm/archive/2009/02/18/3907964.aspx

            posted on 2010-12-18 18:41 風(fēng)輕云淡 閱讀(3336) 評(píng)論(6)  編輯 收藏 引用 所屬分類: C++

            FeedBack:
            # re: 游戲消息效率之switch...case && if...else  2010-12-18 20:46 清正
            有趣, 深入到匯編底層了。 還是第一次意識(shí)到呢。 不錯(cuò)!  回復(fù)  更多評(píng)論
              
            # re: 游戲消息效率之switch...case && if...else  2010-12-19 14:05 wildpointer
            switch...case的翻譯與case的數(shù)目和case的值的范圍有關(guān)。
            如果case少,那么和if...else...差不多。
            如果case較多,分兩種情況
            1:case的值較集中,如你的例子,1,2,3,4,10,那么會(huì)生成一個(gè)表。
            2:case的值較分散,編譯器會(huì)用二分查找的方式確定執(zhí)行哪個(gè)case。
              回復(fù)  更多評(píng)論
              
            # re: 游戲消息效率之switch...case && if...else  2010-12-20 10:06 曾濤
            樓上right,如果就兩個(gè)case,0和全f,難道生成4G個(gè)條目?

            如果不開優(yōu)化的話switch效率是高一些。  回復(fù)  更多評(píng)論
              
            # re: 游戲消息效率之switch...case && if...else [未登錄] 2010-12-20 17:45 123
            跳轉(zhuǎn)表就不說了,不使用跳轉(zhuǎn)表的情況下,很多地方的邏輯都適用二八原則,也就是說用IF ELSE把幾率大的選項(xiàng)寫在前面,比自動(dòng)的二分查找更優(yōu)  回復(fù)  更多評(píng)論
              
            # re: 游戲消息效率之switch...case && if...else  2010-12-21 15:34 Let me see see
            看到一個(gè)游戲引擎中接受消息的部分,原來都是用if..else接受處理,在加大到幾百條消息后速度明顯不如switch

            不清楚這種情況下編譯器如何給if...else做優(yōu)化  回復(fù)  更多評(píng)論
              
            # re: 游戲消息效率之switch...case && if...else  2010-12-23 09:45 李現(xiàn)民
            switch語句被匯編翻譯的結(jié)果與case的長(zhǎng)度及數(shù)值規(guī)律有密切關(guān)系,并不是簡(jiǎn)單的翻譯成跳轉(zhuǎn)表, 同時(shí)與編譯器的優(yōu)化能力也有關(guān)。

            你可以看一下這篇文章:
            http://www.shnenglu.com/besterChen/archive/2009/12/07/102682.html  回復(fù)  更多評(píng)論
              
            青青草原综合久久大伊人| 日本国产精品久久| 69国产成人综合久久精品| 九九精品99久久久香蕉| 国产午夜精品理论片久久 | 思思久久99热免费精品6| 亚洲午夜久久久久久久久电影网 | 久久青青草原亚洲av无码app| 国产精品视频久久久| 久久亚洲国产成人影院网站 | 久久热这里只有精品在线观看| 久久久久亚洲AV无码永不| 久久91这里精品国产2020| 97久久国产露脸精品国产| 国产成人精品久久亚洲| 久久天天躁狠狠躁夜夜不卡| 国产一区二区三精品久久久无广告| 亚洲欧美伊人久久综合一区二区| 国产激情久久久久影院| 久久婷婷五月综合色奶水99啪| 久久中文精品无码中文字幕| 日韩精品国产自在久久现线拍| 热99RE久久精品这里都是精品免费 | 成人妇女免费播放久久久| 性做久久久久久久久浪潮| 久久99精品久久久久久不卡| 久久免费视频观看| 久久久久亚洲av无码专区| 一本色道久久88精品综合| 漂亮人妻被中出中文字幕久久| 久久久久亚洲AV无码专区网站| 久久青青草原国产精品免费| 少妇久久久久久被弄高潮| 国产成人精品综合久久久| 久久婷婷五月综合色奶水99啪 | 久久亚洲国产精品一区二区| 亚洲av成人无码久久精品| 久久精品国产免费观看三人同眠| 无码人妻少妇久久中文字幕 | 国产福利电影一区二区三区久久久久成人精品综合 | 国产亚洲美女精品久久久2020|