为什么不能在C＃中将字符串串联自动转换为StringBuilder？ [英] Why isn't string concatenation automatically converted to StringBuilder in C#?
问题描述
有一天，我向我的一个朋友大喊特雷里克的特定控件。我告诉他，生成控件树花了几秒钟，分析后发现它在循环中使用的是字符串连接，而不是StringBuilder。
One day I was ranting about a particular Telerik control to a friend of mine. I told him that it took several seconds to generate a controls tree, and after profiling I found out that it is using a string concatenation in a loop instead of a StringBuilder. After rewriting it worked almost instantaneously.
因此，我的朋友听到了这个消息，似乎感到惊讶，C＃编译器没有像Java编译器那样自动进行这种转换。阅读许多埃里克·利珀特（Eric Lippert）的答案后，我意识到此功能之所以无法实现，是因为它不够值得。但是，假设地，如果实施它的成本很小，那么有什么理由可以阻止这样做呢？
So my friend heard that and seemed to be surprised that the C# compiler didn't do that conversion automatically like the Java compiler does. Reading many of Eric Lippert's answers I realize that this feature didn't make it because it wasn't deemed worthy enough. But if, hypothetically, costs were small to implement it, what rationale would stop one from doing it?
推荐答案
我注意到是
为什么String.Concat没有针对StringBuilder.Append进行优化？
因此应该将其关闭。
但是，假设地，如果实施它的成本很小，那么有什么理由可以阻止这样做？
But if, hypothetically, costs were small to implement it, what rationale would stop one from doing it?
听起来您正在提出一个重言式：如果没有理由不做X，那么是否有理由不做X？不。
It sounds like you're proposing a bit of a tautology: if there is no reason to not do X, then is there a reason to not do X? No.
我知道知道假设的反事实问题的答案的价值很小。也许要问的一个更好的问题是关于真实世界的问题：
I see little value in knowing the answers to hypothetical, counterfactual questions. Perhaps a better question to ask would be a question about the real world:
是否有使用
Are there programming languages that use this optimization?
是。在JScript.NET中，我们在循环中检测字符串连接，编译器将它们转换为对字符串生成器的调用。
Yes. In JScript.NET, we detect string concatenations in loops and the compiler turns them into calls to a string builder.
随后可能会跟进：
有哪些JScript .NET和C＃之间的差异可以证明一种语言进行了优化，而另一种语言则没有进行优化？
What are some of the differences between JScript .NET and C# that justify the optimization in the one language but not in the other?
JScript的核心假设。 NET的程序员将主要是JavaScript程序员，其中许多人已经建立了必须在任何ECMAScript实现中运行的库。那些程序员可能不太了解.NET框架，即使他们非常了解.NET框架，也可能在不使其库代码不可移植的情况下无法使用StringBuilder。可以合理地假设JavaScript程序员可以是新手程序员，也可以是通过业务而不是计算机科学专业学习编程的程序员。
A core assumption of JScript.NET is that its programmers are mostly going to be JavaScript programmers, and many of them will have already built libraries that must run in any implementation of ECMAScript. Those programmers might not know the .NET framework well, and even if they do, they might not be able to use StringBuilder without making their library code non-portable. It is also reasonable to assume that JavaScript programmers may be either novice programmers, or programmers who came to programming via their line of business rather than a course of study in computer science.
C＃程序员更有可能很好地了解.NET框架，编写与该框架一起使用的库，并且是有经验的程序员，他们了解为什么循环字符串串联在O（n 2 ）中是O天真的实现。他们需要较少的由编译器生成的优化，因为他们认为必要时就可以自己进行优化。
C# programmers are far more likely to know the .NET framework well, to write libraries that work with the framework, and to be experienced programmers who understand why looped string concatenation is O(n2) in the naive implementation. They need this optimization generated by the compiler less because they can just do it themselves if they deem it necessary.
简而言之：编译器功能是要花费我们的预算为客户增加价值；与将功能添加到C＃相比，将功能添加到JScript.NET会获得更多的收益。
In short: compiler features are about spending our budget to add value for the customer; you get more "bang for buck" adding the feature to JScript.NET than you do adding it to C#.
这篇关于为什么不能在C＃中将字符串串联自动转换为StringBuilder？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
