效能殺手之異常霸氣外露!找死!

2021-09-23 12:25:26 字數 2454 閱讀 7952

在上篇:週末淺說--未將物件引用設定到物件的例項(system.nullreferenceexception)中,介紹了乙個比較經典的異常。

文中並淺出一些個人觀點,又潛伏一些觀點。

本節將從上篇的文章中,引申潛伏在上文的另乙個主題異常霸氣外露!找死!

先不說網友以前是怎麼認識try catch和異常的處理,這裡先給出兩個示例**:

static

object

a;static

void

main(

string

args)

}catch

}watch.stop();

system.console.writeline(watch.elapsedmilliseconds);

console.read();}

本機的結論是:0毫秒

這裡只是想最直白的說明一下:加乙個判斷,並不影響效能。

2:迴圈1次,拋異常並捕獲

static

object

a;static

void

main(

string

args)

}catch

}watch.stop();

system.console.writeline(watch.elapsedmilliseconds);

console.read();

本機的結論是:2毫秒

這裡只是想最直白的說明一下:1個異常的丟擲的時間,能擋住60萬次的判斷。

這個結論同時表明:加判斷,並不是不重視效能,反而正是效能最直白的體現。

在個人的印象中,前人就有文章指出異常對效能的影響,當然這個可能年代太久了,大夥沒啥印象了。

今天本人只是換個角度,換個方式,去傳達這麼一種理念:異常應該避免,而不是捕獲,捕獲,那是不得已而為之。

這裡再順路推出微軟乙個讓人糾心的未處理的異常:dictionary的add方法:

if(!

dic.containskey(key))

catch}

正常的寫法,是不用加try catch,可是微軟也不是百分百完美的,就像***注釋的異常,有一定的小概率會拋異常出來,不得已捕獲之。

好,懂事的看完上面的內容,基本都明白事理了,下面再扯幾句給不怎麼懂事的清閒清閒:

霸氣外露!找死!-- 這是發哥在讓子彈飛的話,今天借來一用!

這裡從兩個角度上發揮一下:

1:假設我們很注重效能

假充我們很注重效能:現在我們明白了,乙個異常不經易的丟擲,就害我們損失了60萬次的判斷,唉喲媽喂,這得嚇死多少千年蟲!

以前常整天忙碌在用s好還是用b好,精心設計來設計去,減少來減少去,折騰來折騰去還不一定有60萬這麼大數字,現在一看,蒙了!

原來家裡還有這麼乙隻超級大老鼠,整天吃效能,以前竟然沒發現!!!不過今天。。。

異常霸氣外露!找死!

霸氣外露,遇到我們這群效能執法者,純找死!得把你給滅了,滅乙個就是省60萬,滅兩個就是省120萬,滅多幾個,房子車子全有著落了!

2:假設我們不是很關注效能

假設我們不是很關注效能:乙個異常2毫秒,多大點屁事,60萬次判斷?你家的啥cpu?沒個上百次你都不好意思上來說了。

反正秒級以下的都問題不大:拋500個異常也無所謂了,就一兩秒的時間。

g要的是穩定,穩定!!!明了?

不過話說回來,雖然不在乎點時間,可是這。。。

異常霸氣外露!找死!

我們領導最恨的就是異常,還霸氣外露,露多幾下g這飯碗還能握的住麼?不行,不管什麼異常,得堅決的消滅,消滅不掉的,得藏起來,堅決不能讓它外露!

這不,那個車頭不就是霸氣外露,才被埋的麼!!!

順路ps:cyq.data

效能殺手之異常霸氣外露!找死!

在上篇 週末淺說 未將物件引用設定到物件的例項 system.nullreferenceexception 中,介紹了乙個比較經典的異常。文中並淺出一些個人觀點,又潛伏一些觀點。本節將從上篇的文章中,引申潛伏在上文的另乙個主題 異常霸氣外露!找死!先不說以前是怎麼認識try catch和異常的處理,...

警惕無形效能殺手 快取行失效

在我們的程式中,有一類埋藏極深的問題,其可能導致我們的程式效能數量級的下降,它就是快取行失效。它是因為 cpu 的結構設計而導致的,與語言無關。本篇 chat 會以例子的形式介紹問題的表現,介紹相關的背景知識,分析問題的根本,並且給出解決方案。在本場 chat 中,你將了解到以下知識 快取行失效時導...

效能和異常日誌

1 效能日誌主要記錄某個模組執行的時間,用stopwatch來記錄模組執行的時間。如果執行的時間超過設定的時間 如200毫秒 則記錄日誌,如果客戶端響應時間較長,可以通過檢視效能日誌,定位某個模組的出現了問題。2 異常日誌,在try catch 裡把異常資訊 記錄到異常日誌檔案,找到異常相關資訊。3...