ASP.NET(C#) String, StringBuilder 與 StringWriter效能比較

直觀認識：正面交鋒
效能測試1：StringBuilder
第 1 輪測試：用時 312.5 毫秒
第 2 輪測試：用時 421.875 毫秒
第 3 輪測試：用時 453.125 毫秒
第 4 輪測試：用時 421.875 毫秒
第 5 輪測試：用時 453.125 毫秒
效能測試2：StringWriter
第 1 輪測試：用時 406.25 毫秒
第 2 輪測試：用時 453.125 毫秒
第 3 輪測試：用時 421.875 毫秒
第 4 輪測試：用時 437.5 毫秒
第 5 輪測試：用時 437.5 毫秒
效能測試3：String（1/100 資料量）
第 1 輪測試：用時 12406.25 毫秒

您注意到了嗎？
String 串連方式在只有 1/100 資料的測試下，使用時間30倍於 StringBuilder。因此，基於效能的考量，我們絕不推薦這種方式。而 StringBuilder 較之 StringWriter 略勝一籌，具體的原因將在下文中分析。當然，測試存在誤差，但足以說明事實。

StringWriter 與 StringBuilder：誰是強者
StringWriter 位於 System.IO 命名空間內，繼承於 TextWriter。在 .Net Reflector 的反編譯結果中顯示，它的內部事實上是採用 StringBuilder 進行串連。無怪乎 StringWriter 會略遜一籌，它原來僅僅是 StringBuilder 的一個適配（可以稱之為 Adapter 模式）。為什麼 StringBuilder 擁有如此的效率？

您注意到了嗎？
在許多地方，需要 StringWriter 而不是 StringBuilder，例如 XmlTextWriter。

StringBuilder：原因何在
關於 System.Text.StringBuilder 的研究，網上已有不少，其主要原理便是預先以非託管方式分配記憶體，保證文本的修改與擴張，不重新建立一個 String 對象。而 String 對象的建立，便是效能瓶頸所在。它的串連效率遠超過 String，不過在少量的文本串連時，顯然 String 編程時更方便些。