什么时候使用StringBuilder?
我了解了 StringBuilder 的好处。
但如果我想连接 2 个字符串,那么我认为不使用 StringBuilder 会更好(更快)。这是正确的吗?
在什么情况下(字符串数量)使用 StringBuilder 会变得更好?
I understand the benefits of StringBuilder.
But if I want to concatenate 2 strings, then I assume that it is better (faster) to do it without StringBuilder. Is this correct?
At what point (number of strings) does it become better to use StringBuilder?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(12)
我强烈建议您阅读微优化剧场的悲惨悲剧,作者:杰夫·阿特伍德。
它处理简单连接与 StringBuilder 与其他方法。
现在,如果您想查看一些数字和图表,请点击链接;)
I warmly suggest you to read The Sad Tragedy of Micro-Optimization Theater, by Jeff Atwood.
It treats Simple Concatenation vs. StringBuilder vs. other methods.
Now, if you want to see some numbers and graphs, follow the link ;)
这确实是正确的,您可以在以下位置找到很好的解释:
关于字符串和 StringBuilder 的文章
总结:如果您可以一次性连接字符串,那么
您最好不使用 StringBuilder,因为仅进行复制(生成的字符串的长度为预先计算。);
这样的结构
对于像每次都会创建新对象
,因此您应该考虑 StringBuilder。文章最后总结了这些经验法则:
That is indeed correct, you can find why exactly explained very well on :
Article about strings and StringBuilder
Summed up : if you can concatinate strings in one go like
you are better off without StringBuilder for only on copy is made (the length of the resulting string is calculated beforehand.);
For structure like
new objects are created each time, so there you should consider StringBuilder.
At the end the article sums up these rules of thumb :
System.String 是一个不可变的对象 - 这意味着每当您修改其内容时,它都会分配一个新字符串,这需要时间(和内存?)。
使用 StringBuilder 您可以修改对象的实际内容,而无需分配新的内容。
因此,当需要对字符串进行大量修改时,请使用 StringBuilder。
System.String is an immutable object - it means that whenever you modify its content it will allocate a new string and this takes time (and memory?).
Using StringBuilder you modify the actual content of the object without allocating a new one.
So use StringBuilder when you need to do many modifications on the string.
并非如此...如果您连接大字符串或者有很多连接(例如在循环中),则应该使用 StringBuilder。
Not really...you should use StringBuilder if you concatenate large strings or you have many concatenations, like in a loop.
转述一下
我通常对任何代码块使用字符串生成器,这将导致三个或更多字符串的串联。
To paraphrase
I generally use string builder for any block of code which would result in the concatenation of three or more strings.
这是一个简单的测试应用程序来证明这一点:
结果 (以毫秒为单位):
Here is a simple test app to prove the point:
Results (in milliseconds):
没有明确的答案,只有经验法则。我自己的个人规则是这样的:
StringBuilder
。StringBuilder
。如果不是,请使用
StringBuilder
。There's no definitive answer, only rules-of-thumb. My own personal rules go something like this:
StringBuilder
.StringBuilder
.If it isn't, use a
StringBuilder
.由于很难找到一个既不受观点影响又不受骄傲之战影响的解释,因此我想在 LINQpad 上编写一些代码来自己测试一下。
我发现使用小尺寸的字符串而不是使用 i.ToString() 会改变响应时间(在小循环中可见)。
该测试使用不同的迭代序列来将时间测量保持在合理可比较的范围内。
我将在最后复制代码,以便您可以自己尝试(
results.Charts...Dump()
在 LINQPad 之外无法工作)。输出(X轴:测试的迭代次数,Y轴:以刻度为单位的时间):
迭代序列:2,3,4,5,6,7,8,9,10
迭代顺序:10, 20, 30, 40, 50, 60, 70, 80
迭代序列:100, 200, 300, 400, 500
代码(使用 LINQPad 5 编写):
Since it's difficult to find an explanation for this that's not either influenced by opinions or followed by a battle of prides I thought to write a bit of code on LINQpad to test this myself.
I found that using small sized strings rather than using i.ToString() changes response times (visible in small loops).
The test uses different sequences of iterations to keep time measurements in sensibly comparable ranges.
I'll copy the code at the end so you can try it yourself (
results.Charts...Dump()
won't work outside LINQPad).Output (X-Axis: Number of iterations tested, Y-Axis: Time taken in ticks):
Iterations sequence: 2, 3, 4, 5, 6, 7, 8, 9, 10
Iterations sequence: 10, 20, 30, 40, 50, 60, 70, 80
Iterations sequence: 100, 200, 300, 400, 500
Code (Written using LINQPad 5):
是的。但更重要的是,在这种情况下使用普通的
String
可读性要高得多。另一方面,在循环中使用它是有意义的,并且也可以像串联一样具有可读性。我会对引用特定连接数量作为阈值的经验规则持谨慎态度。在循环中(并且仅循环)使用它可能同样有用,更容易记住并且更有意义。
Yes. But more importantly, it is vastly more readable to use a vanilla
String
in such situations. Using it in a loop, on the other hand, makes sense and can also be as readable as concatenation.I’d be wary of rules of thumb that cite specific numbers of concatenation as a threshold. Using it in loops (and loops only) is probably just as useful, easier to remember and makes more sense.
只要您可以实际键入串联数量(a + b + c ...),就不会有太大区别。 N 平方(N = 10)是 100 倍的减速,这应该不会太糟糕。
最大的问题是当您连接数百个字符串时。当 N=100 时,速度会减慢 10000 倍。这很糟糕。
As long as you can physically type the number of concatenations (a + b + c ...) it shouldn't make a big difference. N squared (at N = 10) is a 100X slowdown, which shouldn't be too bad.
The big problem is when you are concatenating hundreds of strings. At N=100, you get a 10000X times slowdown. Which is pretty bad.
单个串联不值得使用 StringBuilder。根据经验,我通常使用 5 个串联。
A single concatenation is not worth using a StringBuilder. I've typically used 5 concatenations as a rule of thumb.
我认为何时使用或何时不使用之间没有明确的界限。当然,除非有人进行了一些广泛的测试来得出黄金条件。
对我来说,如果只是连接 2 个巨大的字符串,我不会使用 StringBuilder。如果存在计数不确定的循环,我很可能会这样做,即使循环可能计数很小。
I don't think there's a fine line between when to use or when not to. Unless of course someone performed some extensive testings to come out with the golden conditions.
For me, I will not use StringBuilder if just concatenating 2 huge strings. If there's loop with an undeterministic count, I'm likely to, even if the loop might be small counts.