• <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>

            Bugs

            MMORPG game develop.

            [引用]RTTI、虛函數和虛基類的開銷分析及使用指導

            RTTI、虛函數和虛基類的開銷分析及使用指導

            白楊

             

            “在正確的場合使用恰當的特性” 對稱職的C++程序員來說是一個基本標準。想要做到這點,首先要了解語言中每個特性的實現方式及其開銷。本文主要討論相對于傳統C而言,對效率有影響的幾個C++新特性。

            C++引入的額外開銷體現在以下兩方面:

            編譯時開銷

            模板、類層次結構、強類型檢查等新特性,以及大量使用了這些新特性的C++模板、算法庫都明顯地增加了C++編譯器的負擔。但是應當看到,這些新機能在不增加程序執行效率的前提下,明顯降低了廣大C++程序員的工作量。

            用幾秒鐘的CPU時間換取程序員幾小時的辛勤勞動,附帶節省了日后debug和維護代碼的時間,這點開銷當算超值。

            當然,在使用這些特性的時候,也有不少優化技巧。比如:編譯一個大型軟件時,幾條顯式實例化指令就可能使編譯速度提高幾十倍;恰當地組合使用部分專門化和完全專門化,不但可以最優化程序的執行效率,還可以讓同時使用多種不同參數實例化模板的軟件體積顯著減小……

             

            運行時開銷

            運行時開銷恐怕是程序員最關心的問題之一了。相對與傳統C程序而言,C++中有可能引入額外運行時開銷的新特性包括:
            1. 虛基類
            2. 虛函數
            3. RTTI(dynamic_cast和typeid)
            4. 異常
            5. 對象的構造和析構

            關于其中第四點 異常,對于幾乎所有的現代編譯器來說,在正常情況(未拋出異常)下,try塊中的代碼執行效率和普通代碼一樣高,而且由于不再需要使用傳統上通過返回值或函數調用來判斷錯誤的方式,代碼的實際執行效率還會進一步提高。拋出和捕捉異常的效率也只是在某些情況下會高于函數返回和函數調用的效率,何況對于一個編寫良好的程序,拋出和捕捉異常的機會應該不多。關于異常使用的詳細討論,參見:C++編碼規范正文。

            而第五點對象的構造和析構開銷也不總是存在。對于不需要初始化/銷毀的類型,并沒有構造和析構的開銷,相反對于那些需要初始化/銷毀的類型來說,即使用傳統的C方式實現,也至少需要與之相當的開銷。

            對能夠真正用于開發的編譯器而言,C++本身就是使用C/匯編 加以千錘百煉的優化才實現的。也就是說,想用C甚至匯編更高效地實現某個C++特性幾乎是不可能的。要是真能做到這一點的話,大俠就應該去寫個編譯器造福廣大程序員才對~

            C++之所以比C“低效”,其根本原因在于:由于對某些特性的實現方式及其開銷不夠了解,導致程序員在錯誤的位置使用了錯誤的特性。而這些錯誤基本都集中在:

            • 把異常當作另一種流程控制機制,而不是僅將其用于錯誤處理中
            • 濫用或不正確地使用RTTI、虛函數和虛基類機制

            其中第一點上文已經 講過,下面討論第二點。

            為了說明RTTI、虛函數和虛基類的實現方式,首先給出一個實例及其具體實現(為了便于理解,這里故意忽略了一些無關緊要的優化):


            圖中虛箭頭代表偏移,實箭頭代表指針

            由上圖得到每種特性的運行時開銷如下:
             
            特性 時間開銷 空間開銷
            RTTI 幾次整形比較和一次取址操作(可能還會有1、2次整形加法) 每類型一個type_info對象(包括類型ID和類名稱),典型情況下小于32字節

             

            虛函數 一次整形加法和一次指針引用 每類型一個虛表,典型情況下小于32字節

            每對象若干個(大部分情況下是一個)虛表指針,典型情況下小于8字節

             

            虛基類 從直接虛繼承的子類(例如上圖中的 "B1" 和 "B2",但不包括 "DD" )中訪問虛基類的數據成員或其虛函數時,將增加兩次指針引用(大部分情況下可以優化為一次)和一次整形加法。 每類型一個虛基類表,典型情況下小于16字節

            每對象若干虛基類表指針,典型情況下小于8字節

             

             

             * 其中“每類型”或“每對象”是指用到該特性的類型/對象。對于未用到這些功能的類型及其對象,則不會增加上述開銷

            可見,關于老天爺“餓時掉餡餅、睡時掉老婆”等美好傳說純屬謠言。但凡人工制品必不完美,總有設計上的取舍,有其適應的場合也有其不適用的地方。

            C++中的每個特性,都是從程序員平時的生產生活中逐漸精化而來的。在不正確的場合使用它們必然會引起邏輯、行為和性能上的問題。對于上述特性,應該只在必要、合理的前提下才使用。

            "dynamic_cast" 用于在類層次結構中漫游,對指針或引用進行自由的向上、向下或交叉強制。"typeid" 則用于 獲取一個對象或引用的確切類型,與 "dynamic_cast" 不同,將 "typeid" 作用于指針通常是一個錯誤, 要得到一個指針指向之對象的type_info,應當先將其解引用(例如:typeid(*p))。

            一般地講,能用虛函數解決的問題就不要用 "dynamic_cast",能夠用 "dynamic_cast" 解決的就不要用 "typeid"。比如:



            void
            rotate(
            IN const CShape& iS)
            {
               
            if (typeid(iS) == typeid(CCircle))
                {
                   
            // ...
                }
               
            else if (typeid(iS) == typeid(CTriangle))
                {
                   
            // ...
                }
               
            else if (typeid(iS) == typeid(CSqucre))
                {
                   
            // ...
                }

               
            // ...
            }

            以上代碼用 "dynamic_cast" 寫會稍好一點,當然最好的方式還是在其中每個類里定義名為 "rotate" 的虛函數。

            虛函數是C++運行時多態特性中開銷最小,也最常用的機制。虛函數的好處和作用這里不再多說,應當注意在對性能有苛刻要求的場合,或者需要頻繁調用,對性能影響較大的地方(比如每秒鐘 要調用上百次的事件處理函數)要慎用虛函數。

            作為一種支持多繼承的面向對象語言,虛基類有時是保證類層次結構正確的一種必不可少的手段。在需要頻繁使用基類提供的服務,又對性能要求較高的場合,應該避免使用虛基類。

            在基類中沒有數據成員的場合,也可以解除使用虛基類。例如,在上圖中,如果類 "BB" 中不存在數據成員,那么 "BB" 就可以作為一個普通基類分別被 "B1" 和 "B2" 繼承。這樣的優化在達到相同效果的前提下,解除了虛基類引起的開銷。不過這種優化也會帶來一些問題:從 "DD" 向上強制到 "BB" 時會引起歧義;破壞了類層次結構的邏輯關系。

            上述特性的空間開銷一般都是可以接受的,當然也存在一些特例,比如:在存儲布局需要和傳統C結構兼容的場合、在考慮對齊的場合、在需要為一個本來很小的類同時實例化許多對象的場合等等。

            posted on 2008-03-27 17:48 Bugs 閱讀(1283) 評論(1)  編輯 收藏 引用

            評論

            # re: [引用]RTTI、虛函數和虛基類的開銷分析及使用指導 2008-03-27 19:10 Bugs

            除了原文提到的幾點,還是來總結幾點吧,
            可能我個人比較偏好性能,c++的新特性建議不要隨意使用。

            1.在設計和抽象過程中,把繼承的次數降到最小,避免每次構造對象時,
            需要構造很多層父類中的構造函數。

            2.盡量使用C風格的類型轉換
            float f = 3.14;
            int i = (int)f;
            這樣與使用static_cast作用一樣,性能沒有什么區別,
            但dynamic_cast就不一樣了,效率上大大低于static_cast,
            dynamic_cast可以自己使用ObjType來處理一個對象的正確的造型,
            這樣做,只是麻煩了點,但有了更多的靈活性,和性能。
            CXxx *x = 0;
            if( obj->GetType() == TYPE_XXX )
            {
            x = (CXxx*)obj;
            }
            其實只有在一般不明確類型的時候才會使用dynamic_cast進行造型的,
            但在實際編程中,這樣的情況很少。
              回復  更多評論   

            久久这里只精品国产99热| 久久精品成人影院| 日韩欧美亚洲综合久久| 久久久久久久尹人综合网亚洲 | 久久精品青青草原伊人| 97精品国产97久久久久久免费| 无码人妻精品一区二区三区久久| 日韩欧美亚洲综合久久| 久久久噜噜噜久久中文字幕色伊伊 | 精品久久久久久亚洲| 99久久亚洲综合精品成人| 国产成人久久精品区一区二区| 国产精品久久久久蜜芽| 欧洲精品久久久av无码电影| 国产精品久久久久久久人人看| 国产91久久精品一区二区| 久久亚洲国产精品一区二区| 久久久久亚洲av成人无码电影 | 久久综合狠狠综合久久激情 | 麻豆亚洲AV永久无码精品久久| 国内精品久久久久伊人av| 久久亚洲AV成人出白浆无码国产| 久久综合狠狠综合久久97色| 精品999久久久久久中文字幕| 成人妇女免费播放久久久 | 久久婷婷五月综合国产尤物app| 久久久久亚洲AV无码专区网站| 久久丫精品国产亚洲av| 久久夜色撩人精品国产| 超级碰久久免费公开视频| 国产亚洲精午夜久久久久久 | 久久亚洲国产精品123区| 欧洲性大片xxxxx久久久| 亚洲精品无码久久久久sm| 久久久国产视频| 99久久精品国产一区二区| 国产人久久人人人人爽| 亚洲天堂久久精品| 久久亚洲AV成人无码| 麻豆成人久久精品二区三区免费| 久久久久免费视频|