ASP.NET(C#) String, StringBuilder 与 StringWriter性能比较
程序员文章站
2023-09-20 12:37:00
直观认识:正面交锋 性能测试1:stringbuilder 第 1 轮测试:用时 312.5 毫秒 ...
直观认识:正面交锋
性能测试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。在 .net reflector 的反编译结果中显示,它的内部事实上是采用 stringbuilder 进行连接。无怪乎 stringwriter 会略逊一筹,它原来仅仅是 stringbuilder 的一个适配(可以称之为 adapter 模式)。为什么 stringbuilder 拥有如此的效率?
您注意到了吗?
在许多地方,需要 stringwriter 而不是 stringbuilder,例如 xmltextwriter。
stringbuilder:原因何在
关于 system.text.stringbuilder 的研究,网上已有不少,其主要原理便是预先以非托管方式分配内存,保证文本的修改与扩张,不重新创建一个 string 对象。而 string 对象的创建,便是性能瓶颈所在。它的连接效率远超过 string,不过在少量的文本连接时,显然 string 编程时更方便些。
性能测试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。在 .net reflector 的反编译结果中显示,它的内部事实上是采用 stringbuilder 进行连接。无怪乎 stringwriter 会略逊一筹,它原来仅仅是 stringbuilder 的一个适配(可以称之为 adapter 模式)。为什么 stringbuilder 拥有如此的效率?
您注意到了吗?
在许多地方,需要 stringwriter 而不是 stringbuilder,例如 xmltextwriter。
stringbuilder:原因何在
关于 system.text.stringbuilder 的研究,网上已有不少,其主要原理便是预先以非托管方式分配内存,保证文本的修改与扩张,不重新创建一个 string 对象。而 string 对象的创建,便是性能瓶颈所在。它的连接效率远超过 string,不过在少量的文本连接时,显然 string 编程时更方便些。