直观认识：正面交锋
性能测试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编程时更方便些。