秋天是收获的季节。柿子树上缀满了小红灯笼似的柿子,沉甸甸的,把枝头都压弯了。枫树的叶子火红火红的,像一堆正在燃烧的火焰。那梧桐树的枯叶在秋风中纷纷飘落下来,像翩翩起舞的金色蝴蝶。
直观认识:正面交锋 性能测试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其它相关文章!