问Javascript中的字符串连接与字符串缓冲区

EN

**编辑:我假设人们还在看这篇文章--但它已经3+多年了，所以为了你的最大利益，你可以直接查看：http://jsperf.com/string-concatenation/14

查看这篇文章的变化，看看它以前是怎么说的。

即使它是真的并且join()比连接更快，这也无关紧要。我们在这里讨论的毫秒数是完全可以忽略的。

我总是喜欢结构良好和易于阅读的代码，而不是微观的性能提升，我认为使用连接看起来更好，更容易阅读。

这只是我的两个观点。

在我的系统上(Windows7中的IE 8)，StringBuilder在该测试中的时间范围约为70%-100% --也就是说，它不稳定--尽管平均值约为正常追加的95%。

虽然现在很容易说“过早优化”(我怀疑几乎在所有情况下都是)，但还是有一些事情值得考虑：

重复字符串连接的问题来自重复的内存分配和重复的数据复制(高级字符串数据类型可以减少/消除很多这样的问题，但现在让我们继续假设一个简单的模型)。因此，让我们提出一些问题：

• 使用什么内存分配？在简单的情况下，每个str+=x都需要str.length+x.length分配新的内存。例如，标准的C malloc是一个相当糟糕的内存分配器。多年来，JS实现经历了一些变化，其中包括更好的内存子系统。当然，这些更改并没有止步于此，还触及了现代JS代码的所有方面。因为现在古老的实现在某些任务中可能已经非常慢，这并不意味着同样的问题仍然存在，或者在相同的程度上。
• 与上面的Array.join的实现是非常重要的。如果在构建之前没有为最后一个字符串预先分配内存，那么它只会节省数据复制成本--现在的主内存是多少GB/s ? 10,000 x 50很难达到极限。使用糟糕的内存分配器的智能Array.join操作应该会执行得更好一些，因为重新分配的数量减少了。随着分配成本的降低，这种差异有望最小化。
• 微基准代码可能存在缺陷，这取决于JS引擎是否为每个唯一的字符串文字创建一个新对象。(这会使它偏向Array.join方法，但需要从总体上考虑)。
• 基准测试确实是一个微型基准测试:)增加不断增长的大小应该会对性能产生影响，这是基于以上任何一个或所有(然后是一些)条件。通常很容易显示出偏爱某种方法的极端情况--预期的用例通常更重要。

尽管，老实说，对于任何形式的正常字符串构建，我只会使用普通的字符串连接，直到这样的时候，它被确定为瓶颈。

我会重新读一遍书中的上面这句话，看看作者是否真的有其他隐含的考虑因素，比如“对于非常大的字符串”，或者“大量的字符串操作”，或者“在JScript/IE6中”等等。如果不是，那么这样的语句就像"Insert sort is O(n*n)“一样有用。实现成本取决于数据的状态和n的大小。

免责声明:代码的速度取决于浏览器、操作系统、底层硬件、月球引力，当然还有你的电脑对你的感觉。