关于StringBuilder的抄作与神话 (转)
编码的发展似乎总是在简单与复杂之间不断徘徊，一代又一代的高手程序员们乐此不疲。当你把部分工作交给电脑时，一切都简单了，但电脑毕竟是电脑，于是高手们渐渐提出不满并把工作收回，接着又一批高手制造再优的程序逻辑，大家把工作还给电脑，如此往复循环。。。
在任意搜索引擎找一下.NET效率优化就不难发现StringBuilder的身影，同时对于String的批驳也随处可见。自从有了String这个类，“+”的操作就始终伴随我们，如今这位战功显赫的朋友却承担着巨大的压力，还不断被双规去解释CPU和内存的使用问题。经过网络上的一翻调查，感觉有必要将部分真象告诉大家，故事就从这里说起：
《Performance considerations for strings in C#》一文据说是由Dr Herbie完成，并且经过Teddy Tam的翻译（网上太多地方转载，就不贴链接了）。文中对StringBuilder.Append和String“+”进行了解释和分析，并且给出了特定测试结果和报告。应当说真象是令人震憾的，甚至有些无奈的感觉。原来StringBuilder 通常只有在你要连接的字符串数目超过 600 时才会显示出真正的性能优势，当然在垃圾回收的问题上还有另外的好处。虽然作者只是进行的简单而特定的测试和分析，但也应当能够说明一些问题。
接下来我又在网上进一步地找了找，发现StringBuilder和String的比较很多“高手”似乎有些情绪化，下面我们冷静地谈谈：
1.StringBuilder本身使用时要初始化这个对象，这个可消耗不算小。
2.StringBuilder在指定容量时效果更明显，否则它也是不断分配内存。
3.String的“+”本身其实效率不算低，或者说还挺高，只是用法上导致了坏的结果。 例如
string str = "wer" + "slfls" + 。。。。。 + "lsfs";
还是相当有效得，理论上优于StringBuilder.Append。 只是因为追求代码规范而改写为：
string str = "wer"; str += "slfls";.......致使临时内存泛滥。 4.String.Contact 和
String.Join是两大利器。其效果同样优于StringBuilder,至少是相差无几。
而"+"正是得益于.NET编译时优化为String.Contact。
5.String.Contact也有软肋，那就是支持object的参数。
程序员用的时候爽到了，但机器却不断调用ToString()，而对于ArrayList还得装拆箱。
6.不论你用什么方法，基本上运行时间及内存消耗上的差距在同一个数量级中。
即使你循环上百万次也不过如此，除非你并发百万次估计难以看到根本性变化。
有位仁兄对此做了些尝试，也许范围有些片面，但对于像我一样的寻常程序员足已。
参看： http://www.cnblogs.com/xingd/archive/2005/02/06/102380.html
有时人云亦云实在是容易制造幻觉，也不知是哪位首先发起对StringBuilder的号召。甚至有人提出它就是微软搞出来替代“+”的，这实在是说不过去。StringBuilder不止有Append一个方法，在创建一个内存文本流方面它也是相当实用的，用它来替代临时文件估计比耗在String问题上作用要大的多。
就我本人感觉而言，有时我们是应当忽略相当的效率的，而且也是很必要的。效率的优化不仅仅来自于代码，应当说首先立足于业务逻辑，精简的业务关系和流程是源头；其次是从设计上考虑，基于良好的设计基础想低效都不容易;再次是硬件和软件平台，这上面的差距常常能莫名奇妙地省却很多麻烦；最后才轮到代码上，而且也应该是着眼主干代码，比如SQL的优化或缓存使用通常更解决问题。
转:http://blog.csdn.net/zbjg/archive/2007/03/23/1538924.aspx
在任意搜索引擎找一下.NET效率优化就不难发现StringBuilder的身影，同时对于String的批驳也随处可见。自从有了String这个类，“+”的操作就始终伴随我们，如今这位战功显赫的朋友却承担着巨大的压力，还不断被双规去解释CPU和内存的使用问题。经过网络上的一翻调查，感觉有必要将部分真象告诉大家，故事就从这里说起：
《Performance considerations for strings in C#》一文据说是由Dr Herbie完成，并且经过Teddy Tam的翻译（网上太多地方转载，就不贴链接了）。文中对StringBuilder.Append和String“+”进行了解释和分析，并且给出了特定测试结果和报告。应当说真象是令人震憾的，甚至有些无奈的感觉。原来StringBuilder 通常只有在你要连接的字符串数目超过 600 时才会显示出真正的性能优势，当然在垃圾回收的问题上还有另外的好处。虽然作者只是进行的简单而特定的测试和分析，但也应当能够说明一些问题。
接下来我又在网上进一步地找了找，发现StringBuilder和String的比较很多“高手”似乎有些情绪化，下面我们冷静地谈谈：
1.StringBuilder本身使用时要初始化这个对象，这个可消耗不算小。
2.StringBuilder在指定容量时效果更明显，否则它也是不断分配内存。
3.String的“+”本身其实效率不算低，或者说还挺高，只是用法上导致了坏的结果。 例如
string str = "wer" + "slfls" + 。。。。。 + "lsfs";
还是相当有效得，理论上优于StringBuilder.Append。 只是因为追求代码规范而改写为：
string str = "wer"; str += "slfls";.......致使临时内存泛滥。 4.String.Contact 和
String.Join是两大利器。其效果同样优于StringBuilder,至少是相差无几。
而"+"正是得益于.NET编译时优化为String.Contact。
5.String.Contact也有软肋，那就是支持object的参数。
程序员用的时候爽到了，但机器却不断调用ToString()，而对于ArrayList还得装拆箱。
6.不论你用什么方法，基本上运行时间及内存消耗上的差距在同一个数量级中。
即使你循环上百万次也不过如此，除非你并发百万次估计难以看到根本性变化。
有位仁兄对此做了些尝试，也许范围有些片面，但对于像我一样的寻常程序员足已。
参看： http://www.cnblogs.com/xingd/archive/2005/02/06/102380.html
有时人云亦云实在是容易制造幻觉，也不知是哪位首先发起对StringBuilder的号召。甚至有人提出它就是微软搞出来替代“+”的，这实在是说不过去。StringBuilder不止有Append一个方法，在创建一个内存文本流方面它也是相当实用的，用它来替代临时文件估计比耗在String问题上作用要大的多。
就我本人感觉而言，有时我们是应当忽略相当的效率的，而且也是很必要的。效率的优化不仅仅来自于代码，应当说首先立足于业务逻辑，精简的业务关系和流程是源头；其次是从设计上考虑，基于良好的设计基础想低效都不容易;再次是硬件和软件平台，这上面的差距常常能莫名奇妙地省却很多麻烦；最后才轮到代码上，而且也应该是着眼主干代码，比如SQL的优化或缓存使用通常更解决问题。
转:http://blog.csdn.net/zbjg/archive/2007/03/23/1538924.aspx
