原文寫于：八月 9 2011 11:08 上午

?

公司里新上了一個項目，在做性能測試的時候發現一個奇怪的問題，跑同一個流程，在一個48核（HP580 G7 PC server）的服務器上耗時120秒，而在一個4核心的PC機上只要90秒，帶著這樣的疑問，公司請了微軟的相關工程師來解決此問題。

經過一天的跟蹤調試和優化，把耗時降至70幾秒，這其中過程包含幾個.net對象的優化，確實效果很明顯。此文是階段性結論的一個筆記，也蠻具有指導意義。

?

一、DataView.ToTable()后的性能問題

工程師在跟蹤代碼的時候發現處理這個方法的時候很慢，占居了整個邏輯代碼的大部分時間。優化這個方法后效果很明顯。

查了MSDN，官方并沒有給出DataView.ToTable()方法關于性能方面的提示，但是要MSDN看這個方法時，發現老外在06年的時候已經在下面回了一段代碼，通過三個方式執行這個方法，發現效率上差異很大。 （MSDN：DataView.ToTable()）。

我復制代碼，創建了一個新的工程，確實可以重現問題。整個過程大概如下：

背景是有一個有500000條數據的DataTable，然后把這個DataTable中的數據賦給DataView，然后從這個DataView通過ToTable()方法，把數據轉給另外一個同架構的DataTable。

第一種方式 創建目標DataTable對象，直接通過toTable()方法轉換。過程耗時：27.0504秒。

第二種方式 創建目標DaTaTable后，對其設置PrimaryKey。然后通過下面代碼向目標表添加數據。

? ? ? ? ? ? ? ???foreach (DataRow dr in ds.Tables[0].Rows)

? ? ? ? ? ? ? ? {

? ? ? ? ? ? ? ? ? ? DataRow[] drrepetido = dsRes.Tables[0].Select("valor=" + dr["Valor"]);

? ? ? ? ? ? ? ? ? ? if (drrepetido.Length == 0)

? ? ? ? ? ? ? ? ? ? ? ? dsRes.Tables[0].ImportRow(dr);

? ? ? ? ? ? ? ? }

過程耗時：11.7624秒。

?

第三種方式 不根據原架構創建目標DataTable，全新實例化DataTable對象，然后向其添加對應列，然后創建哈希表，循環寫入目標表，代碼如下：

? ? ? ? ? ? ? ??DataTable dt = new DataTable();

? ? ? ? ? ? ? ? dt.Columns.Add("valor", ds.Tables[0].Columns["valor"].DataType);

? ? ? ? ? ? ? ? Hashtable ht = new Hashtable();

? ? ? ? ? ? ? ? foreach (DataRow dr in ds.Tables[0].Rows)

? ? ? ? ? ? ? ? {

? ? ? ? ? ? ? ? ? ? if (!ht.ContainsKey(dr[0]))

? ? ? ? ? ? ? ? ? ? {

? ? ? ? ? ? ? ? ? ? ? ? ht.Add(dr[0], null);

? ? ? ? ? ? ? ? ? ? ? ? DataRow newRow = dt.NewRow();

? ? ? ? ? ? ? ? ? ? ? ? newRow[0] = dr[0];

? ? ? ? ? ? ? ? ? ? ? ? dt.Rows.Add(newRow);

? ? ? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? }

過程耗時：0.2184秒。

?

三種方式對比，發現非常恐怖。但是微軟好像還沒有給出原因。

?

二、StringBuilder()使用不檔帶來的性能問題

?

關于StringBuilder之前也看過很多文章，這次開發商程序中的問題和以前的類似，實例化時沒有設置一個比較推薦的長度值，導致在循環體內不斷appand()后，StringBuilder對象不斷被GC處理。從而消耗了很多時間。

關于StringBuilder()對象，還是再多加幾句吧。其默認維護的Capacity值是16。

因為StringBuilder對象的創建代價較大，在字符串連接目標較少的情況下，過度濫用StringBuilder會導致性能的浪費而非節約。只有大量的或者無法預知次數的字符串操作，才考慮以StringBuilder來實現。 ?String類型的“＋”連接操作，實際上是重載操作符“＋”調用String.Concat來操作，而編譯器則會優化這種連接操作的處理，編譯器根據其傳入參數的個數，一次性分配相應的內存，并依次拷入相應的字符串。 StringBuilder在使用上，最好指定合適的容量值，否則由于默認容量不足而頻繁的進行內存分配操作，是不妥的實現方法。 ?通常情況下，進行簡單字符串連接時，應該優先考慮使用String.Concat和String.Join等操作來完成字符串的連接，但是應該留意String.Concat可能存在的裝箱操作。

?

三、拆裝箱帶來性能問題

如果用StringBuilder.toString().trim()來判斷StringBuilder是否有值的情況，可以用StringBuilder.Lenth()來代替。

?

?

其它等等

轉載于:https://www.cnblogs.com/redroot/archive/2013/01/24/2875843.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的趁热打铁-一次.Net WebService的性能优化之旅的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。