为什么 String.Concat 没有针对 StringBuilder.Append 进行优化? [英] Why is String.Concat not optimized to StringBuilder.Append?

问题描述

我发现编译器将常量字符串表达式的连接优化为一个字符串.

I found concatenations of constant string expressions are optimized by the compiler into one string.

现在只有在运行时才知道字符串的字符串连接，为什么编译器不优化循环中的字符串连接和超过 10 个字符串的连接以使用 StringBuilder.Append 代替?我的意思是，有可能，对吧?实例化一个 StringBuilder 并获取每个连接并将其转换为 Append() 调用.

Now with string concatenation of strings only known at run-time, why does the compiler not optimize string concatenation in loops and concatenations of say more than 10 strings to use StringBuilder.Append instead? I mean, it's possible, right? Instantiate a StringBuilder and take each concatenation and turn it into an Append() call.

是否有任何理由为什么这应该或可以不被优化?我错过了什么?

Is there any reason why this should or could not be optimized? What am I missing?

推荐答案

肯定的答案必须来自编译器设计团队.但让我在这里试一试...

The definite answer will have to come from the compiler design team. But let me take a stab here...

如果您的问题是，为什么编译器不转这个:

If your question is, why the compiler doesn't turn this:

string s = "";
for( int i = 0; i < 100; i ++ )
    s = string.Concat( s, i.ToString() );

进入这个:

StringBuilder sb = new StringBuilder();
for( int i = 0; i < 100; i++ )
    sb.Append( i.ToString() );
string s = sb.ToString();

最可能的答案是这不是优化.这是对代码的重写，基于开发人员的知识和意图引入了新的结构 - 而不是编译器.

The most likely answer is that this is not an optimization. This is a rewrite of the code that introduces new constructs based on knowledge and intent that the developer has - not the compiler.

这种类型的更改需要编译器对 BCL 有更多的了解，而不是适当的.如果明天有一些更优化的字符串组装服务可用怎么办?编译器应该使用它吗?

This type of change would require the compiler to have more knowledge of the BCL than is appropriate. What if tomorrow, some more optimal string assembly service becomes available? Should the compiler use that?

如果您的循环条件更复杂怎么办，编译器是否应该尝试执行一些静态分析来确定这种重写的结果在功能上是否仍然等效?在许多方面，这就像解决停机问题.

What if your loop conditions were more complicated, should the compiler attempt to perform some static analysis to decide whether the result of such a rewrite would still be functionally equivalent? In many ways, this would be like solving the halting problem.

最后，我不确定在所有情况下这都会导致代码执行速度更快.实例化 StringBuilder 并将其内部缓冲区大小调整为文本已附加.事实上，追加的成本与被连接的字符串的大小、有多少、内存压力看起来如何密切相关.这些都是编译器无法提前预测的.

Finally, I'm not sure that in all cases this would result in faster performing code. There is a cost to instantiating a StringBuilder and resizing its internal buffer as text is appended. In fact, the cost of appending is strongly tied to the size of the string being concatenated, how many there are, what memory pressure looks like. These are things that the compiler cannot predict in advance.

作为开发人员，您的工作是编写性能良好的代码.编译器只能通过进行某些安全、保持不变的优化来提供帮助.不是为您重写代码.

It's your job as a developer to write well-performing code. The compiler can only help by making certain safe, invariant-preserving optimizations. Not rewriting your code for you.

这篇关于为什么 String.Concat 没有针对 StringBuilder.Append 进行优化?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！