直观认识：正面交锋
性能测试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性能比较】相关文章：
★ this connector is disabled错误的解决方法
★ ASP.NET State service状态服务的问题解决方法
★ asp.net+js实现的ajax sugguest搜索提示效果
★ asp.net aspnetpager分页统计时与实际不符的解决办法
★ ASP.NET通过Remoting service上传文件