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

            [引用]More Effective C++ 條款15


            條款15:了解異常處理的系統(tǒng)開銷


            為了在運(yùn)行時處理異常,程序要記錄大量的信息。無論執(zhí)行到什么地方,程序都必須能夠識別出如果在此處拋出異常的話,將要被釋放哪一個對象;程序必須知道每一個入口點(diǎn),以便從try塊中退出;對于每一個try塊,他們都必須跟蹤與其相關(guān)的catch子句以及這些catch子句能夠捕獲的異常類型。這種信息的記錄不是沒有代價的。確保程序滿足異常規(guī)格不需要運(yùn)行時的比較(runtime comparisons),而且當(dāng)異常被拋出時也不用額外的開銷來釋放相關(guān)的對象和匹配正確的catch字句。但是異常處理確是有代價的,即使你沒有使用try,throw或catch關(guān)鍵字,你同樣得付出一些代價。


            讓我們先從你不使用任何異常處理特性也要付出的代價談起。你需要空間建立數(shù)據(jù)結(jié)構(gòu)來跟蹤對象是否被完全構(gòu)造(constructed)(參加條款10),你也需要系統(tǒng)時間保持這些數(shù)據(jù)結(jié)構(gòu)不斷更新。這些開銷一般不是很大,但是當(dāng)采用不支持異常的方法編譯的程序一般比支持異常的程序運(yùn)行速度更快所占空間也更小。


            在理論上,你不能對此進(jìn)行選擇:C++編譯器必須支持異常,也就是說,當(dāng)你不用異常處理時你不能讓編譯器生產(chǎn)商消除這方面的開銷,因?yàn)槌绦蛞话阌啥鄠€獨(dú)立生成的目標(biāo)文件(object files)組成,只有一個目標(biāo)文件不進(jìn)行異常處理并不能代表其他目標(biāo)文件不進(jìn)行異常處理。而且即使組成可執(zhí)行文件的目標(biāo)文件都不進(jìn)行異常處理,那么還有它們所連接的程序庫呢?如果程序的任何部分使用了異常,其它部分必須也支持異常。否則在運(yùn)行時程序就不可能提供正確的異常處理。


            不過這只是理論,實(shí)際上大部分支持異常的編譯器生產(chǎn)商都允許你自由控制是否在生成的代碼里包含進(jìn)支持異常的內(nèi)容。如果你知道你程序的任何部分都不使用try,throw或catch,并且你也知道所連接的程序庫也沒有使用try,throw或catch,你就可以采用不支持異常處理的方法進(jìn)行編譯,這可以縮小程序的尺寸和提高速度,否則你就得為一個不需要的特性而付出代價。隨著時間的推移,使用異處理的程序庫開始變得普遍了,上面這種方法將逐漸不能使用,但是根據(jù)目前的軟件開發(fā)情況來看,如果你已經(jīng)決定不使用任何的異常特性,那么采用不支持異常的方法編譯程序是一個性能優(yōu)化的合理方法。同樣這對于想避開異常的程序庫來說也是一個性能優(yōu)化的好方法,這能保證異常不會從客戶端程序傳遞進(jìn)程序庫里,不過同時這樣做也會妨礙客戶端程序重定義程序庫中聲明的虛擬函數(shù),并不允許有在客戶端定義的回調(diào)函數(shù)。


            使用異常處理的第二個開銷來自于try塊,無論何時使用它,也就是無論何時你想能夠捕獲異常,那你都得為此付出代價。不同的編譯器實(shí)現(xiàn)try塊的方法不同,所以編譯器與編譯器間的開銷也不一樣。粗略地估計,如果你使用try塊,代碼的尺寸將增加5%-10%并且運(yùn)行速度也同比例減慢。這還是假設(shè)程序沒有拋出異常,我這里討論的只是在程序里使用try塊的開銷。為了減少開銷,你應(yīng)該避免使用無用的try塊。


            編譯器為異常規(guī)格生成的代碼與它們?yōu)?span>try塊生成的代碼一樣多,所以一個異常規(guī)格一般花掉與try塊一樣多的系統(tǒng)開銷。什么?你說你認(rèn)為異常規(guī)格只是一個規(guī)格而已,你認(rèn)為它們不會產(chǎn)生代碼?那么好,現(xiàn)在你應(yīng)該對此有新的認(rèn)識了。


            現(xiàn)在我們來到了問題的核心部分,看看拋出異常的開銷。事實(shí)上我們不用太關(guān)心這個問題,因?yàn)楫惓J呛苌僖姷模@種事件的發(fā)生往往被描述為exceptional(異常的,罕見的)。80-20規(guī)則(參見條款16)告訴我們這樣的事件不會對整個程序的性能造成太大的影響。但是我知道你仍舊好奇地想知道如果拋出一個異常到底會有多大的開銷,答案是這可能會比較大。與一個正常的函數(shù)返回相比,通過拋出異常從函數(shù)里返回可能會慢三個數(shù)量級。這個開銷很大。但是僅僅當(dāng)你拋出異常時才會有這個開銷,一般不會發(fā)生。但是如果你用異常表示一個比較普遍的狀況,例如完成對數(shù)據(jù)結(jié)構(gòu)的遍歷或結(jié)束一個循環(huán),那你必須重新予以考慮。

            posted on 2008-03-27 17:06 Bugs 閱讀(998) 評論(4)  編輯 收藏 引用

            評論

            # re: [引用]More Effective C++ 條款15 2008-03-27 17:14 Bugs

            我自己對異常處理的心得有下列幾點(diǎn),僅供參考,希望大家說說各自的意見。
            1.盡量避免使用異常處理,能不能則不用,可以用C Style的Error處理方式來代替。(對于渴望性能很實(shí)用)
            2.即使要使用,也一定把Scope降到最低,盡量減少多重嵌套。
            3.如果整個生產(chǎn)系統(tǒng)使用了不穩(wěn)定的第三方庫,建議使用異常處理,畢竟服務(wù)器穩(wěn)定勝于性能。  回復(fù)  更多評論   

            # re: [引用]More Effective C++ 條款15 2008-03-31 22:41 Fox

            對異常處理沒有特別關(guān)注過,搬著板凳先看到  回復(fù)  更多評論   

            # re: [引用]More Effective C++ 條款15 2008-04-01 15:11 酷勤網(wǎng)

            哪里有這本書的網(wǎng)上譯文?  回復(fù)  更多評論   

            # re: [引用]More Effective C++ 條款15 2008-04-03 13:58 Bugs

            不知道,你去找找吧  回復(fù)  更多評論   


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            精品久久久久久亚洲精品 | 亚洲国产精品无码久久一线| 久久无码专区国产精品发布| 久久人妻AV中文字幕| 久久久亚洲欧洲日产国码二区| 热久久这里只有精品| 性做久久久久久久久老女人| 无码人妻精品一区二区三区久久久| 99久久国产综合精品麻豆| 久久久综合香蕉尹人综合网| 中文字幕热久久久久久久| 四虎国产精品免费久久久| 日韩欧美亚洲综合久久| 狠狠色丁香婷婷久久综合不卡| 午夜视频久久久久一区 | 国产精品伦理久久久久久| 久久久这里有精品| 久久久中文字幕| 人妻无码αv中文字幕久久琪琪布| 国产成人综合久久久久久| 91精品国产91久久综合| 精品综合久久久久久97| 久久综合亚洲色HEZYO国产| 一本大道久久a久久精品综合| 久久亚洲AV成人无码国产 | 无码精品久久久天天影视| 免费一级欧美大片久久网| 99久久精品免费| 国内精品久久久久久久97牛牛| 99精品国产免费久久久久久下载| 日韩精品国产自在久久现线拍| 久久国产精品无码一区二区三区| 国产成人精品三上悠亚久久| 久久天天婷婷五月俺也去| 天天影视色香欲综合久久| 久久久久人妻一区精品 | 国产成人久久精品麻豆一区| 精品国产福利久久久| 久久久久久a亚洲欧洲aⅴ| 青青青青久久精品国产| 久久久国产精华液|