除了前面的答案，当我想到这样的问题时，我总是做的第一件事是创建一个小型测试应用程序。在这个应用程序中，为这两种情况执行一些计时测试，看看哪个更快。

恕我直言，添加500+字符串条目绝对应该使用StringBuilder。

除了前面的答案，当我想到这样的问题时，我总是做的第一件事是创建一个小型测试应用程序。在这个应用程序中，为这两种情况执行一些计时测试，看看哪个更快。

恕我直言，添加500+字符串条目绝对应该使用StringBuilder。

一个简单的例子来演示使用String连接和StringBuilder在速度上的差异:

System.Diagnostics.Stopwatch time = new Stopwatch();
string test = string.Empty;
time.Start();
for (int i = 0; i < 100000; i++)
{
    test += i;
}
time.Stop();
System.Console.WriteLine("Using String concatenation: " + time.ElapsedMilliseconds + " milliseconds");

结果:

使用字符串串联:15423毫秒

StringBuilder test1 = new StringBuilder();
time.Reset();
time.Start();
for (int i = 0; i < 100000; i++)
{
    test1.Append(i);
}
time.Stop();
System.Console.WriteLine("Using StringBuilder: " + time.ElapsedMilliseconds + " milliseconds");

结果:

使用StringBuilder: 10毫秒

结果，第一次迭代花费了15423毫秒，而使用StringBuilder的第二次迭代花费了10毫秒。

在我看来，使用StringBuilder更快，快得多。

作为一般的经验法则，如果我必须设置字符串的值不止一次，或者如果字符串有任何追加，那么它需要是一个字符串构建器。在了解字符串构建器之前，我曾经看到我过去编写的应用程序具有巨大的内存足迹，而且似乎一直在不断增长。将这些程序更改为使用字符串构建器可以显著减少内存使用。现在我对琴弦制造者发誓。

字符串连接将花费更多。 在Java中，您可以根据需要使用StringBuffer或StringBuilder。 如果您想要一个同步的、线程安全的实现，请使用StringBuffer。这将比字符串连接更快。

如果你不需要同步的或者线程安全的实现，选择StringBuilder。 这将比String连接更快，也比StringBuffer更快，因为它们没有同步开销。

是的，性能差异是显著的。请参阅KB文章“如何在Visual c#中提高字符串连接性能”。

我总是试着先编写清晰的代码，然后再优化性能。这比反过来做要容易得多!但是，看到了两者在我的应用程序中的巨大性能差异后，我现在更仔细地考虑了一下。

幸运的是，在代码上运行性能分析相对简单，可以看到您在哪些地方花费了时间，然后在需要的地方修改它以使用StringBuilder。