秋天是收获的季节。柿子树上缀满了小红灯笼似的柿子，沉甸甸的，把枝头都压弯了。枫树的叶子火红火红的，像一堆正在燃烧的火焰。那梧桐树的枯叶在秋风中纷纷飘落下来，像翩翩起舞的金色蝴蝶。
直观认识：正面交锋 性能测试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。在.NetReflector的反编译结果中显示，它的内部事实上是采用StringBuilder进行连接。无怪乎StringWriter会略逊一筹，它原来仅仅是StringBuilder的一个适配（可以称之为Adapter模式）。为什么StringBuilder拥有如此的效率？ 您注意到了吗？
在许多地方，需要StringWriter而不是StringBuilder，例如XmlTextWriter。 StringBuilder：原因何在
关于System.Text.StringBuilder的研究，网上已有不少，其主要原理便是预先以非托管方式分配内存，保证文本的修改与扩张，不重新创建一个String对象。而String对象的创建，便是性能瓶颈所在。它的连接效率远超过String，不过在少量的文本连接时，显然String编程时更方便些。
以上就是ASP.NET(C#) String, StringBuilder 与 StringWriter性能比较。一生很短，努力赚钱，钱能让你做自己想做的事，钱能让你爱得更好，钱会使你快乐。更多关于ASP.NET(C#) String, StringBuilder 与 StringWriter性能比较请关注haodaima.com其它相关文章！