一次连接一个字符串效率低下吗？

我回想起用C语言进行编程的日子，当两个字符串连接在一起时，操作系统必须为连接的字符串分配内存，然后程序可以将所有字符串文本复制到内存中的新区域，然后旧内存必须手动进行被发布。因此，如果像加入列表一样多次执行此操作，则OS必须不断分配越来越多的内存，只是要在下一个串联后释放它。用C语言执行此操作的更好方法是确定组合字符串的总大小，并为整个连接的字符串列表分配必要的内存。

现在，在现代编程语言（例如C＃）中，我通常会看到遍历集合的内容，方法是遍历集合并将所有字符串一次全部添加到单个字符串引用中。即使具有现代计算能力，这也不低效吗？

您至少在我熟悉的语言（C，Java，C＃）中对为什么效率低下的解释是准确的，尽管我不同意执行大量字符串连接普遍存在。在C＃代码，我的工作，有丰富的使用StringBuilder，String.Format等等这些都是记忆保存techiniques避免过度再分配。

因此，要回答您的问题，我们必须提出另一个问题： 如果串联字符串从来就不是真正的问题，为什么类会喜欢StringBuilder并StringBuffer存在？为什么甚至在初学者编程书籍和类中都包含此类的使用？为什么看似过早的优化建议如此突出？

如果大多数使用字符串连接的开发人员的答案完全基于经验，那么大多数人会说这永远不会有所作为，并且会避免使用此类工具，而采用“更具可读性”的方法for (int i=0; i<1000; i++) { strA += strB; }。 但是他们从来没有测量过。

这个问题的真正答案可以在SO答案中找到，它揭示了在一个实例中，当连接50,000个字符串（取决于您的应用程序，这很常见）时，甚至很小的字符串，都可能导致性能提高1000倍。

如果性能从字面上根本不代表任何意义，则必须将其连接起来。但是我不同意使用替代方法（StringBuilder）困难或可读性差，因此这是一种合理的编程实践，不应调用“过早优化”防御。

更新：

我认为这可以归结为了解您的平台并遵循其最佳实践，而遗憾的是，这些最佳实践并不普遍。来自两种不同“现代语言”的两个示例：

1. 在另一个SO答案中，在JavaScript中有时发现完全相反的性能特征（array.join vs + =）是正确的。在某些浏览器中，字符串连接似乎是自动优化的，而在其他情况下则不是。因此，建议（至少在该SO问题中）是串联而不用担心。
2. 在另一种情况下，Java编译器可以用更有效的结构（例如StringBuilder）自动替换串联。但是，正如其他人指出的那样，这是不确定的，不能保证，并且使用StringBuilder不会损害可读性。在这种特殊情况下，我倾向于建议不要将串联用于大型集合，也不要依赖于不确定的Java编译器行为。同样，在.NET中，永远不会执行排序优化。

马上就不了解每个平台的每一个细微差别，这并不是一个主要的罪过，但是忽略这样的重要平台问题，几乎就像是从Java到C ++，而不是关心释放内存。

大致由于您所描述的原因，它效率不高。C＃和Java中的字符串是不可变的。与C中不同，对字符串的操作将返回一个单独的实例，而不是修改原始实例。在连接多个字符串时，每个步骤都会创建一个单独的实例。分配和稍后垃圾收集那些未使用的实例可能会导致性能下降。只有这次，垃圾收集器才为您处理内存管理。

C＃和Java都引入了StringBuilder类作为专门用于此类任务的可变字符串。C语言中的等效项将使用串联字符串的链接列表，而不是将它们连接到数组中。C＃还为字符串提供了一种方便的Join方法，用于加入字符串集合。

严格来说，使用CPU周期的效率较低，因此您是对的。但是，开发人员的时间，维护成本等情况如何。如果将时间成本加到等式中，最简单的方法通常总是效率更高，然后在需要时分析和优化慢速位。
“程序优化的第一条规则：不要做。程序优化的第二条规则（仅供专家使用！）：还不要做。”

如果没有实际测试，很难说出任何有关性能的信息。最近，我很惊讶地发现，在JavaScript中，单纯的字符串连接通常比推荐的“ make list and join”解决方案要快（在这里进行测试，将t1与t4进行比较）。我仍然对为什么会发生感到困惑。

在对性能进行推理时（尤其是在内存使用方面），您可能会问以下几个问题：1）我的输入有多大？2）我的编译器有多聪明？3）我的运行时如何管理内存？这并不详尽，但这是一个起点。

1. 我的投入有多大？

   复杂的解决方案通常具有固定的开销，可能以要执行的额外操作的形式出现，或者可能需要额外的内存。由于这些解决方案是为处理大案件而设计的，因此实现者通常不会出现额外费用的问题，因为净收益比微优化代码更为重要。因此，如果您的输入足够小，那么天真的解决方案可能会比复杂的解决方案具有更好的性能，仅是为了避免这种开销。（尽管确定“足够小”是困难的部分）

2. 我的编译器有多聪明？

   许多编译器非常聪明，可以“优化”写入但从未读取的变量。同样，一个好的编译器也许也可以将一个简单的字符串连接转换为一个（核心）库使用，并且，如果其中许多是在没有任何读取的情况下进行的，那么在这些操作之间就无需将其转换回字符串（即使您的源代码似乎就是这样做的。我无法确定是否有任何编译器可以执行此操作，或者执行的程度如何（AFAIK Java至少将同一表达式中的多个concat替换为一系列StringBuffer操作），但这是有可能的。

3. 我的运行时如何管理内存？

   在现代CPU中，瓶颈通常不是处理器，而是缓存。如果您的代码在短时间内访问了许多“远程”内存地址，则在高速缓存级别之间移动所有内存所需的时间将超过所使用指令中的大多数优化。这在具有分代垃圾回收器的运行时中尤其重要，因为最近创建的变量（例如，在同一函数范围内）通常位于连续的内存地址中。这些运行时通常还会在方法调用之间来回移动内存。

   它可能会影响字符串连接的一种方式（免责声明：这是一个疯狂的猜测，我还不足以肯定地说），如果是为朴素的用户分配的内存是否接近使用它的其余代码（甚至如果它多次分配和释放它），而为库对象分配的内存却远不及它（因此，在代码计算，库消耗，代码计算更多等过程中，许多上下文都会发生更改，等等）会导致许多缓存未命中。当然对于大输入OTOH，无论如何都会发生高速缓存未命中，因此多重分配的问题变得更加明显。

就是说，我不是在提倡使用这种方法，而只是在测试，性能分析和基准测试之前，应先进行任何有关性能的理论分析，因为当今大多数系统太复杂，以至于没有足够的专业知识就无法完全理解。

乔尔（Joel）不久前就这一主题写了一篇很棒的文章。正如其他人指出的那样，它在很大程度上取决于语言。由于在C中实现字符串的方式（零终止，没有长度字段），因此标准的strcat库例程效率很低。乔尔（Joel）提出了一个替代方案，只需稍作改动即可，效率更高。

一次连接一个字符串效率低下吗？

没有。

您是否读过“微优化剧院的悲剧”？