• <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
            <2015年5月>
            262728293012
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(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)樗商?,特別是當(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ì)非常量的情況是無(wú)能為力的。例如 if (a > 1 && a < 100),是無(wú)法使用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語(yǔ)句被匯編翻譯的結(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)論
              
            久久er国产精品免费观看2| 九九热久久免费视频| 99久久人妻无码精品系列蜜桃| 国产一级做a爰片久久毛片| 人人狠狠综合久久亚洲| 久久精品亚洲中文字幕无码麻豆| 国产一区二区三精品久久久无广告| 亚洲伊人久久成综合人影院| 99国产精品久久| 久久婷婷五月综合97色直播| yellow中文字幕久久网| 久久久无码一区二区三区| 要久久爱在线免费观看| 国产激情久久久久影院| 精品熟女少妇av免费久久| 7777精品伊人久久久大香线蕉| 18岁日韩内射颜射午夜久久成人 | segui久久国产精品| 无遮挡粉嫩小泬久久久久久久| 亚洲伊人久久综合中文成人网| 亚洲国产天堂久久综合网站| 国产午夜福利精品久久2021| 亚洲精品第一综合99久久| 久久久网中文字幕| 国产精品免费久久久久久久久| 国产精品美女久久久久| 久久99国产综合精品免费| 色婷婷综合久久久中文字幕| 国内精品久久久久影院薰衣草| 一级做a爰片久久毛片看看| 久久亚洲精品无码播放| 精品多毛少妇人妻AV免费久久| 日本精品久久久久中文字幕| 久久国产亚洲精品麻豆| 精品无码久久久久久尤物| 久久99精品久久只有精品| 精品无码久久久久国产| 久久精品国产影库免费看| 久久最近最新中文字幕大全 | 日本福利片国产午夜久久| 久久电影网2021|