When is it better to use String.Format vs string concatenation?

我看了一下 String。格式(使用反射器) ，并且它实际上创建了一个 StringBuilder，然后在其上调用 AppendFormat。因此，它比连接的多次搅拌更快。最快的方法(我相信)是创建一个 StringBuilder 并手动调用 Append。当然，“许多”的数量是可以猜测的。 我会使用 + (实际上 & 因为我是一个 VB 程序员大部分)的东西像你的例子。当它变得更复杂时，我使用 String。格式。如果有很多变量，那么我会使用 StringBuilder 和 Append，例如，我们有构建代码的代码，在那里我使用一行实际的代码来输出一行生成的代码。

似乎有一些关于为每个操作创建多少字符串的推测，所以让我们举几个简单的例子。

"C" + rowIndex.ToString();

“ C”已经是一个字符串了。
rowIndex.ToString() creates another string. (@manohard - no boxing of rowIndex will occur)
然后我们得到最后一根弦。
If we take the example of

String.Format("C(0)",rowIndex);

then we have "C{0}" as a string
将 rowIndex 装箱以传递给函数
创建了一个新的字符串构造器
在字符串构建器上调用 AppendFormat ——我不知道 AppendFormat 如何运行的细节，但是让我们假设它非常高效，它仍然需要将装箱的 rowIndex 转换为字符串。
然后将字符串构建器转换为新的字符串。
I know that StringBuilders attempt to prevent pointless memory copies from taking place but the String.Format still ends up with extra overhead compared to the plain concatenation.

如果我们现在举一个有更多字符串的例子

"a" + rowIndex.ToString() + "b" + colIndex.ToString() + "c" + zIndex.ToString();

we have 6 strings to start with, which will be the same for all cases.
使用连接，我们还有4个中间字符串加上最终的结果。使用 String、 Format (或 StringBuilder)消除的是那些中间结果。
请记住，要创建每个中间字符串，必须将前一个中间字符串复制到新的内存位置，而不仅仅是内存分配可能比较慢。

绳子。当格式模板(“ C {0}”)存储在配置文件(比如 Web.config/App.config)中时，格式可能是更好的选择

I did a bit of profiling of various string methods including string.Format, StringBuilder and string concatenation. String concatenation almost always outperformed the other methods of building strings. So, if performance is key, then its better. However, if performance is not critical then I personally find string.Format to be easier to follow in code. (But that's a subjective reason) StringBuilder however, is probably most efficient with respect to memory utilization.

我最初的偏好(来自 C + + 背景)是 String。格式。我后来放弃了这个，原因如下:

• 字符串连接可以说是“更安全”。在我身上发生过(在其他几个开发人员身上也发生过)删除一个参数，或者错误地弄乱参数顺序。编译器不会根据格式字符串检查参数，最终会出现一个运行时错误(也就是说，如果你足够幸运，没有使用一个模糊的方法，比如记录一个错误)。通过连接，删除参数不易出错。你可以说出错的几率非常小，但是却发生了 梅。

字符串串联允许空值，而 String.Format不允许。写入“ s1 + null + s2”不会中断，它只是将空值视为 String。空的。嗯，这可能取决于您的特定场景-有些情况下，您希望出现一个错误，而不是默默地忽略空 FirstName。然而，即使在这种情况下，我个人也更喜欢自己检查 null 并抛出特定的错误，而不是我从 String 获得的标准 ArgumentNullException。格式。

• 字符串连接性能更好。上面的一些帖子已经提到了这一点(但没有解释原因，所以我决定写这篇文章:)。

想法是.NET 编译器足够聪明，可以转换这段代码:

public static string Test(string s1, int i2, int i3, int i4,
string s5, string s6, float f7, float f8)
{
return s1 + " " + i2 + i3 + i4 + " ddd " + s5 + s6 + f7 + f8;
}

回到这里:

public static string Test(string s1, int i2, int i3, int i4,
string s5, string s6, float f7, float f8)
{
return string.Concat(new object[] { s1, " ", i2, i3, i4,
" ddd ", s5, s6, f7, f8 });
}

在 String 的引擎盖下发生了什么。连接很容易猜测(使用反射器)。数组中的对象通过 ToString ()转换为它们的字符串。然后计算总长度，只分配一个字符串(使用总长度)。最后，在某段不安全的代码中，通过 wstrcpy 将每个字符串复制到结果字符串中。

为什么 String.Concat更快？好吧，我们都可以看看 String.Format在做什么-你会对处理格式字符串所需的代码量感到惊讶。除此之外(我已经看到关于内存消耗的注释) ，String.Format在内部使用 StringBuilder。方法如下:

StringBuilder builder = new StringBuilder(format.Length + (args.Length * 8));

So for every passed argument, it reserves 8 characters. If the argument is a one-digit value, then too bad, we have some wasted space. If the argument is a custom object returning some long text on ToString(), then there might be even some reallocation needed (worst-case scenario, of course).

与此相比，串联只会浪费对象数组的空间(考虑到它是一个引用数组，不会浪费太多)。没有对格式说明符的解析，也没有中间的 StringBuilder。两种方法都存在装箱/取消装箱开销。

我选 String 的唯一原因。格式是当涉及到本地化时。将格式字符串放在资源中可以支持不同的语言，而不会影响代码(考虑一下格式化值根据语言改变顺序的情况，即“在{0}小时和{1}分钟之后”在日语中可能看起来非常不同:)。

总结一下我的第一篇(也是相当长的)文章:

• 对我来说，最好的方法(在性能与可维护性/可读性方面)是使用字符串串联，而不需要任何 ToString()调用
• 如果你是在性能之后，使 ToString()调用自己，以避免装箱(我有点偏向于可读性)-同样的第一个选项在您的问题
• 如果向用户显示本地化字符串(这里不是这种情况) ，String.Format()有一个边。

关于性能，我更喜欢 String. Format

我同意上面的很多观点，我认为应该提到的另一点是代码的可维护性。绳子。格式允许更容易地更改代码。

也就是说，我有一个信息 "The user is not authorized for location " + location或 "The User is not authorized for location {0}"

if I ever wanted to change the message to say: location + " does not allow this User Access" or "{0} does not allow this User Access"

格式化我所要做的就是改变字符串。 为了连接，我必须修改那条消息

如果在多个地方使用，可以节省很多时间。

在我的印象中，string.format 速度更快，在这个测试中似乎慢了3倍

string concat = "";
System.Diagnostics.Stopwatch sw1 = new System.Diagnostics.Stopwatch    ();
sw1.Start();
for (int i = 0; i < 10000000; i++)
{
concat = string.Format("{0}{1}{2}{3}{4}{5}{6}{7}{8}{9}{10}","1", "2" , "3" , "4" , "5" , "6" , "7" , "8" , "9" , "10" , i);
}
sw1.Stop();
Response.Write("format: "  + sw1.ElapsedMilliseconds.ToString());
System.Diagnostics.Stopwatch sw2 = new System.Diagnostics.Stopwatch();
sw2.Start();
for (int i = 0; i < 10000000; i++)
{
concat = "1" + "2" + "3" + "4" + "5" + "6" + "7" + "8" + "9" + "10" + i;
}
sw2.Stop();

Format 需要4.6秒，使用’+’需要1.6秒。

关于表现:

void Main()
{
var start = CurrentTimeMillis();
for (var i = 0; i < 1000000; i++)
{
var s = "Hi " + i.ToString() + "; Hi to you " + (i * 2).ToString();
}
var end = CurrentTimeMillis();
Console.WriteLine("Concatenation = " + ((end - start)).ToString() + " millisecond");
start = CurrentTimeMillis();
for (var i = 0; i < 1000000; i++)
{
var s = String.Format("Hi {0}; Hi to you {1}", i, +i * 2);
}
end = CurrentTimeMillis();
Console.WriteLine("Format = " + ((end - start)).ToString() + " millisecond");
start = CurrentTimeMillis();
for (var i = 0; i < 1000000; i++)
{
var s = String.Concat("Hi ", i.ToString(), "; Hi to you ", (i * 2).ToString());
}
end = CurrentTimeMillis();
Console.WriteLine("Strng.concat = " + ((end - start)).ToString() + " millisecond");


start = CurrentTimeMillis();
for (int i = 0; i < 1000000; i++)
{
StringBuilder bldString = new StringBuilder("Hi ");
bldString.Append(i).Append("; Hi to you ").Append(i * 2);
}
end = CurrentTimeMillis();
Console.WriteLine("String Builder = " + ((end - start)) + " millisecond");
}


private static readonly DateTime Jan1st1970 = new DateTime
(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);


public static long CurrentTimeMillis()
{
return (long)(DateTime.UtcNow - Jan1st1970).TotalMilliseconds;
}

结果

Concatenation = 69 millisecond
Format = 142 millisecond
Strng.concat = 62 millisecond
String Builder = 91 millisecond

为了进行公平的比较，我实例化了一个新的 StringBuilder，而不是在循环外创建的 StringBuilder (由于循环附加在一个构建器的重新分配空间的末尾，这样可能更快)。