昨天看到 「效能相差7千倍的tostring方法」這篇文章，對於作者這種良好的效能意識和探索精神很佩服，以前還真沒注意到這點。
不過，用switch的做法，個人覺得雖然效能上去了，但是可維護性就下來了，以後該列舉要增加或刪除一項，這段switch**都要改一下，其實該問題的關鍵就是反射帶來的效能損耗，在呼叫列舉的tostring()方法時，無非就是要得到乙個字串而已，我個人更傾向於用key-value這種經典的鍵值對來優化。
下面是示例**：
public static class testclass
public enum enumloginerror
private static void addenumloginerrortodic()
}}
這樣處理後的效能測試**：(asp.net頁中測試的，主要只是對比一下跟傳統tostring方法的差異而已)
protected void page_load(object sender, eventargs e)
sw.stop();
debug.writeline("dictionary方法耗時：" + sw.elapsedmilliseconds);
sw.reset();
//反射方法 計時開始
sw.start();
for (i = 0; i < _max; i++)
sw.stop();
debug.writeline("反射方法 耗時：" + sw.elapsedmilliseconds);
}
在我的本本上跑出來的測試結果如下：
dictionary方法耗時：28
反射方法 耗時：1384
效果還是比較明顯的，相對於switch方法而言，沒有將結果字串硬編碼在處理函式中，以後列舉中增加或刪除某一項，也不影響呼叫**，可維護性相對更好一些。但是也應該看到，這是一種空間換時間的做法，避開了反射，但是系統需要額外儲存乙個字典物件，占用的記憶體要比原來多一些。
也談列舉ToString 效能的改進
昨天看到 效能相差7千倍的tostring方法 這篇文章，對於作者這種良好的效能意識和探索精神很佩服，以前還真沒注意到這點。不過，用switch的做法，個人覺得雖然效能上去了，但是可維護性就下來了，以後該列舉要增加或刪除一項，這段switch 都要改一下，其實該問題的關鍵就是反射帶來的效能損耗，在呼...
幾種toString的效能比較
最近要寫乙個批量的介面，由於一次請求的量比較大，所以很多小的點不得不好好考慮效能。乙個object的tostring操作，也是乙個效能考慮點，故自己做了乙個測試，比較了一下可能的幾種tostring的方式。public static void main string args long endtim...
也談Vista的解除安裝現象
照理說，使用者買了一台預裝 vista 的電腦之後，應該非常高興才對。但是，事實上，並不如此。我有一位朋友，前不久購買了一台 hp v3431au 膝上型電腦，其中預裝了 vista 作業系統，開始很新奇。我也試了一把。不料，才過了乙個來星期時間，他卻把它 格了 徹底解除安裝 我大為吃驚。這 指 v...