StringBuilder与String性能 [英] StringBuilder vs. String performance
问题描述
我认为StringBuilder的重点在于它应该是一个比字符串更快的构建字符串的方式。但是，我只是把
放在一个简单的小应用程序中进行两者之间的比较分析，而且，令人惊讶的是，字符串似乎通过一个字符串来执行StringBuilder
重要金额。字符串连接使用StringBuilder的时间不会比使用字符串长两倍。这对我来说听起来不太合适。有没有其他人在
主题上有任何硬性能数据经验？
这就是我做的 - 我做了一个简单的小应用程序，开始两个worker
个线程，一个使用字符串连接字符串，另一个使用
StringBuilder。每隔一秒，每个工作线程都会向显示它们的UI报告它已执行的连接数。字符串
线程通常每秒运行300万。 StringBuilder大约180万美元兑换
。这是违背你的经验吗？
-
Richard Lewis Haggard
www.Haggard-And-Associates.com
你''必须分享代码才能让任何人做出准确的
评估。
然而，我的经验是，有一定数量在
完成后，新建一个StringBuilder并从中取出字符串的开销。所以你必须做足够的连接才能克服这个问题。例如，如果你使用StringBuilder从一千位构建一个HTML页面
，这将比重复的字符串
连接快得多。在另一个极端，如果你只想附加
一次，那么就不要打扰StringBuilder。交叉点
点会有所不同，但一个好的经验法则是字符串
连接可以用于3个或更少的连接;如果你做得更多的话，考虑一下
StringBuilder。
最后想一想，我不会测试特定的原始性能
功能，同时混合线程问题的复杂性。太多了，这太多了。
--BOB
Richard Lewis Haggard写道：我认为StringBuilder的重点在于它应该是一种比字符串更快的构建字符串的方法。但是，我只是将一个简单的小应用程序放在一起进行两者之间的比较分析，令人惊讶的是，字符串似乎以极大的数量执行StringBuilder。使用StringBuilder进行字符串连接的时间不会比使用字符串长两倍。这对我来说听起来不对。有没有其他人在
主题上有任何硬性能数据经验？
这就是我做的 - 我做了一个简单的小应用程序启动两个工作线程，一个使用字符串连接字符串，另一个使用StringBuilder。每隔一秒，每个工作线程都会向显示它们的UI报告它已执行的连接数。字符串
线程通常以每秒300万的速度运行。 StringBuilder大约有180万。这是否违背或与您的经验相符？
<" Richard Lewis Haggard" < HaggardAtWorldDotStdDotCom>>写道：我认为StringBuilder的重点在于它应该是一种比字符串更快的构建字符串的方法。但是，我只是将一个简单的小应用程序放在一起进行两者之间的比较分析，令人惊讶的是，字符串似乎以极大的数量执行StringBuilder。使用StringBuilder进行字符串连接的时间不会比使用字符串长两倍。这对我来说听起来不对。有没有其他人在
主题上有任何硬性能数据经验？
这就是我做的 - 我做了一个简单的小应用程序启动两个工作线程，一个使用字符串连接字符串，另一个使用StringBuilder。每隔一秒，每个工作线程都会向显示它们的UI报告它已执行的连接数。字符串
线程通常以每秒300万的速度运行。 StringBuilder大约有180万。这是否与您的体验相符或相符？
它同意我将两个字符串连接在一起的经验，并且运行
与我的相反将数百个字符串连接在一起的经验。
你可以和我们分享你的代码吗？
顺便说一下，我会说多个 - 读取基准测试听起来像是一个非常糟糕的想法（除非它实际上是在测试线程）。更好的是
尽可能多地为一个任务提供机器，时间，然后为不同的任务执行相同的操作。这听起来像是你的b $ b相信调度程序是公平的，对于初学者来说......
-
Jon Skeet - < sk *** @ pobox.com>
http：// www.pobox.com/~skeet 博客： http：// www。 msmvps.com/jon.skeet
如果回复该群组，请不要给我发邮件
StringBuilder的优势发生在附加大量字符串。
差异变得可见，附加约35.000字符串或更多。请参阅下面的
代码。
结果是（发布版本，P4 2.8GB）：
of of appends：35.000
字符串+时间：1,42秒
StringBuilder时间：0秒
of of appends：100.000
String +时间：13,961秒
StringBuilder时间：0.01秒
附加次数：200.000
String +时间：72,264秒
StringBuilder时间：0.01秒
=== [CODE] =================== ================
Console.Write（"输入要追加的字符串数量："）;
int count = Convert.ToInt32（Console.ReadLine（））;
string str = null;
int startTick = Environment.TickCount;
for（int i = 0; i< count; i ++）
{
str = str +"。" ;;
}
int endTick = Environment.TickCount;
double timeTakenByPlus =
（endTick - startTick）/ 1000.0;
System.Text.StringBuilder bldr =
new System.Text.StringBuilder（）;
startTick = Environment.TickCount;
for（int i = 0;我<计数; i ++）
{
bldr.Append（"。"）;
}
endTick =环境.TickCount;
double timeTakenByStringBuilder =
（endTick - startTick）/ 1000.0;
Console.Write（ " + and StringBuilder take）;
Console.WriteLine（" {0} and {1} seconds"，
timeTakenByPlus，
timeTakenByStringBuilder）;
============================
< blockquote class =post_quotes>我认为StringBuilder的重点在于它应该是一种比字符串更快的构建字符串的方法。但是，我只是将一个简单的小应用程序放在一起进行两者之间的比较分析，令人惊讶的是，字符串似乎以极大的数量执行StringBuilder。使用StringBuilder进行字符串连接的时间不会比使用字符串长两倍。这对我来说听起来不对。有没有其他人在
主题上有任何硬性能数据经验？
这就是我做的 - 我做了一个简单的小应用程序启动两个工作线程，一个使用字符串连接字符串，另一个使用StringBuilder。每隔一秒，每个工作线程都会向显示它们的UI报告它已执行的连接数。字符串
线程通常以每秒300万的速度运行。 StringBuilder大约有180万。这是违背你的经验吗？
-
WBR，
Michael Nemtsev ::博客： http://spaces.msn.com/laflour
有时一个人仍忠于某一事业，只因为它的反对者不会因为b $ b不再是平淡无奇的。 （c）Friedrich Nietzsche
I thought that the whole point of StringBuilder was that it was supposed to
be a faster way of building strings than string. However, I just put
together a simple little application to do a comparative analysis between
the two and, surprisingly, string seems to out perform StringBuilder by a
significant amount. A string concatenation takes not quite twice as long
using StringBuilder than it does with a string. This doesn''t sound right to
me. Does anyone else have any hard performance data experience on the
subject?
Here''s what I did- I made a simple little app that starts two worker
threads, one uses string to concatenate string and the other uses
StringBuilder. Once a second, each of the worker threads reports the number
of concatenations it has performed to the UI which displays them. The string
thread generally runs at 3 million a second. The StringBuilder turns in
about 1.8 million. Does this run counter or agree with your experience?
--
Richard Lewis Haggard
www.Haggard-And-Associates.com
You''d have to share the code in order for anyone to make an accurate
assessment.
However, my experience is that there''s a certain amount of overhead in
newing up a StringBuilder and getting the string back out of it when
you''re done. So you have to be doing enough concatenation to overcome
that. For example, if you use a StringBuilder to build an HTML page
from a thousand bits, that will be much faster than repeated string
concatenations. At the other extreme if you simply want to append
something once then don''t bother with StringBuilder. The crossover
point will vary somewhat, but a good rule of thumb is that string
concatenation is fine for 3 or fewer concatenations; consider a
StringBuilder if you''re doing more.
As a final thought, I would not test the raw performance of a specific
feature while mixing in the complication of threading issues. It''s apt
to muddy the waters too much.
--Bob
Richard Lewis Haggard wrote:I thought that the whole point of StringBuilder was that it was supposed to
be a faster way of building strings than string. However, I just put
together a simple little application to do a comparative analysis between
the two and, surprisingly, string seems to out perform StringBuilder by a
significant amount. A string concatenation takes not quite twice as long
using StringBuilder than it does with a string. This doesn''t sound right to
me. Does anyone else have any hard performance data experience on the
subject?
Here''s what I did- I made a simple little app that starts two worker
threads, one uses string to concatenate string and the other uses
StringBuilder. Once a second, each of the worker threads reports the number
of concatenations it has performed to the UI which displays them. The string
thread generally runs at 3 million a second. The StringBuilder turns in
about 1.8 million. Does this run counter or agree with your experience?
<"Richard Lewis Haggard" <HaggardAtWorldDotStdDotCom>> wrote:I thought that the whole point of StringBuilder was that it was supposed to
be a faster way of building strings than string. However, I just put
together a simple little application to do a comparative analysis between
the two and, surprisingly, string seems to out perform StringBuilder by a
significant amount. A string concatenation takes not quite twice as long
using StringBuilder than it does with a string. This doesn''t sound right to
me. Does anyone else have any hard performance data experience on the
subject?
Here''s what I did- I made a simple little app that starts two worker
threads, one uses string to concatenate string and the other uses
StringBuilder. Once a second, each of the worker threads reports the number
of concatenations it has performed to the UI which displays them. The string
thread generally runs at 3 million a second. The StringBuilder turns in
about 1.8 million. Does this run counter or agree with your experience?
It agrees with my experience of joining two strings together, and runs
counter to my experience of joining hundreds of strings together.
Could you share your code with us?
I would say, by the way, that multi-threading a benchmark sounds like a
really bad idea (unless it''s actually testing threading). Better is to
give as much of the machine as possible to a single task, time that,
and then do the same for a different task. It sounds like you''re
trusting the scheduler to be fair, for starters...
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
The advantage of StringBuilder take place in appending large number of strings.
Difference became visible in appending about 35.000 strings and more. See
code below.
The results are that (release version, P4 2.8GB):
# of appends: 35.000
String + time: 1,42 sec
StringBuilder time: 0 sec
# of appends: 100.000
String + time: 13,961 sec
StringBuilder time: 0.01 sec
# of appends: 200.000
String + time: 72,264 sec
StringBuilder time: 0.01 sec
===[ CODE ]===================================
Console.Write("Enter number of strings to append:");
int count = Convert.ToInt32(Console.ReadLine());
string str = null;
int startTick = Environment.TickCount;
for (int i = 0; i < count; i++)
{
str = str + ".";
}
int endTick = Environment.TickCount;
double timeTakenByPlus =
(endTick - startTick) / 1000.0;
System.Text.StringBuilder bldr =
new System.Text.StringBuilder();
startTick = Environment.TickCount;
for (int i = 0; i < count; i++)
{
bldr.Append(".");
}
endTick = Environment.TickCount;
double timeTakenByStringBuilder =
(endTick - startTick) / 1000.0;
Console.Write("+ and StringBuilder took ");
Console.WriteLine("{0} and {1} seconds",
timeTakenByPlus,
timeTakenByStringBuilder);
============================
I thought that the whole point of StringBuilder was that it was supposed to
be a faster way of building strings than string. However, I just put
together a simple little application to do a comparative analysis between
the two and, surprisingly, string seems to out perform StringBuilder by a
significant amount. A string concatenation takes not quite twice as long
using StringBuilder than it does with a string. This doesn''t sound right to
me. Does anyone else have any hard performance data experience on the
subject?
Here''s what I did- I made a simple little app that starts two worker
threads, one uses string to concatenate string and the other uses
StringBuilder. Once a second, each of the worker threads reports the number
of concatenations it has performed to the UI which displays them. The string
thread generally runs at 3 million a second. The StringBuilder turns in
about 1.8 million. Does this run counter or agree with your experience?
--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour
"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
这篇关于StringBuilder与String性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
