| 以文本方式查看主題 - 曙海教育集團論壇 (http://m.rfoamep.cn/bbs/index.asp) -- C語言開發 (http://m.rfoamep.cn/bbs/list.asp?boardid=62) ---- 對C#開發的兩個基本原則的深入討論 (http://m.rfoamep.cn/bbs/dispbbs.asp?boardid=62&id=2408) |
| -- 作者：wangxinxin -- 發布時間：2010-12-10 11:37:07 -- 對C#開發的兩個基本原則的深入討論 關于屬性的性能問題需要談一點，如果僅僅是簡單地以存取模式來使用屬性，在相當程度上是沒有性能損失的。因為在JIT編譯過程中已經做了inline的處理。不過inline處理還是有一些基本的條件，有些情況下JIT編譯器不會inline，比如虛調用，方法的IL代碼長度過長（目前CLR的規定是超過32bytes為代碼長度過長），有復雜的控制流邏輯，有異常處理等。這些條件都是要么根本不能使用inline（比如虛屬性），要么inline的代價太大，容易導致代碼的bloat，要么是inline起來很費時間——已經喪失了inline的意義，因為.NET的inline機制發生在JIT過程中。使用屬性有個別讓人感覺不舒服的地方，比如它影響開發人員的開發效率，但對代碼運行的效率不產生影響。 明辨值類型和引用類型的使用場合 這個條款討論的是類型設計時候的tradeoff——是將類型設計為結構還是類。Bill Wagner先生給出了一個原則“值類型用于存儲數據，引用類型用于定義行為（value types store values and reference types define behavior）”。 如何判斷這個原則的適用性，Bill Wagner也給出了一個方法，那就是首先回答下面幾個問題： 1.該類型的主要職責是否用于數據存儲？ 2.該類型的公有接口是否都是一些存取屬性？ 3.是否確信該類型永遠不可能有子類？ 4.是否確信該類型永遠不可能具有多態行為？ 如果所有問題的答案都是yes，那么就應該采用值類型。這樣的判斷確實有很好的理由支撐，但是我個人認為“將這4個問題回答為yes”還不足以構成采用值類型的全部理由。因為在很多項目實踐中，我發現值類型帶來的性能問題不可小視。值類型帶來的性能問題主要有兩個： 1.由于值類型實例在棧和托管堆之間的轉換而導致的box/unbox，以及由此帶來的托管堆上的垃圾。 2.值類型默認情況下采用的是值拷貝語義，如果是比較大的值類型，在傳遞參數和函數返回值時，同樣會帶來性能問題。 關于第1條，Bill Wagner在本條款中提到了“引用類型會給垃圾收集器帶來負擔”這個表面看似正確的判斷。但是由于box/unbox的效應，有些情況下，反倒是值類型給垃圾收集器帶來了更多的負擔。比如將一些值類型放到一個集合中，然后又頻繁地對其進行讀寫操作。如果碰到這種情況，我想“放棄結構而采用類”未嘗不是一種更好的做法。事實上，將一個用作數據存儲的值類型（比如System.Drawing.Point）添加到一個集合（System.Collections.ArrayList）中是一個太常見不過的操作。不過，C# 2.0中新引入的泛型技術對box/unbox的問題有極大的改善。 關于第2條，Scott Meyers先生在Effective C++的第22條“盡量使用pass-by-reference（傳址），少用pass-by-value（傳值）”中講的比較清楚。雖然由于C#中的結構類型具有默認的深拷貝語義，沒有拷貝構造器的調用。而且結構類型也沒有子類，因此在某種程度上來講不具有多態性，也就沒有C++對象傳值時可能出現的切割（slicing）效應。但是值拷貝的成本仍然不小。尤其是在這個值類型比較大的情況下，問題就比較嚴重。實際上，在.NET框架的Design Guidelines for Class Library Developers文檔中，在說明什么時候應該使用結構類型的時候，其中提到了一項原則（還有其他一些并行原則）——類型實例數據的大小要小于16個字節。該文檔主要是從類型的運行效率層面來考慮的，而Bill Wagner先生這里的條款主要是從類型的設計層面來考慮的。 從上述兩條討論來看，我個人傾向于對結構類型采取更為保守的設計策略。而對于類則可以積極大膽地使用。因為“將結構類型不適當地設計為類”帶來的不良后果要遠遠小于“將類不適當地設計為結構類型”所帶來的不良后果。就目前的經驗來看，我甚至認為只有和非托管互操作打交道的情況才是使用結構類型最充足的理由，其他情況都要“三思而后行”。當然，在C# 2.0中引入泛型技術之后，box/unbox將不再是一個沉重的負擔，應付一些非常輕量級的場合，結構類型依然有自己的一席之地。 |