|
|
性能測試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 數(shù)據(jù)量）
第 1 輪測試：用時 12406.25 毫秒
您注意到了嗎？
String 連接方式在只有 1/100 數(shù)據(jù)的測試下，使用時間30倍于 StringBuilder。因此，基于性能的考量，我們絕不推薦這種方式。而 StringBuilder 較之 StringWriter 略勝一籌，具體的原因?qū)⒃谙挛闹蟹治觥．?dāng)然，測試存在誤差，但足以說明事實。
StringWriter 與 StringBuilder：誰是強(qiáng)者
StringWriter 位于 System.IO 命名空間內(nèi)，繼承于 TextWriter。在 .NET Reflector 的反編譯結(jié)果中顯示，它的內(nèi)部事實上是采用 StringBuilder 進(jìn)行連接。無怪乎 StringWriter 會略遜一籌，它原來僅僅是 StringBuilder 的一個適配（可以稱之為 Adapter 模式）。為什么 StringBuilder 擁有如此的效率？
您注意到了嗎？
在許多地方，需要 StringWriter 而不是 StringBuilder，例如 XmlTextWriter。
StringBuilder：原因何在
關(guān)于 System.Text.StringBuilder 的研究，網(wǎng)上已有不少，其主要原理便是預(yù)先以非托管方式分配內(nèi)存，保證文本的修改與擴(kuò)張，不重新創(chuàng)建一個 String 對象。而 String 對象的創(chuàng)建，便是性能瓶頸所在。它的連接效率遠(yuǎn)超過 String，不過在少量的文本連接時，顯然 String 編程時更方便些。
AspNet技術(shù)：ASP.NET(C#) String, StringBuilder 與 StringWriter性能比較，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
