My experience was that [].join('') has shown some really wired behaviour, so i fel back to + :-/
–
martyonairMar 19 '12 at 0:27

I know the fundamental question here is about string concatenation but you should use caution when creating html elements like this. Your example could break if the url contains ' or \n.
–
styfleJul 24 '13 at 20:24

13 Answers
13

Internet Explorer is the only browser which really suffers from this in today's world. (Versions 5, 6, and 7 were dog slow. 8 does not show the same degradation.) What's more, IE gets slower and slower the longer your string is.

If you have long strings to concatenate then definitely use an array.join technique. (Or some StringBuffer wrapper around this, for readability.) But if your strings are short don't bother.

Your example is not a good one in that it is very unlikely that the performance will be signficantly different. In your example readability should trump performance because the performance gain of one vs the other is negligable. The benefits of an array (StringBuffer) are only apparent when you are doing many concatentations. Even then your mileage can very depending on your browser.

Here is a detailed performance analysis that shows performance using all the different JavaScript concatenation methods across many different browsers; String Performance an Analysis

"First things first with the performance improvements with IE7, we no longer need to consider using an alternate path when doing large scale string operations; using Array.join in an iterative situation gives you no major advantages than using += in the same situation. In addition, the differences with IE6 were slight enough to allow you to not bother forking for that specific version."
–
Chris SJan 11 '11 at 11:08

2

@Chris, that's not true. Compare these two fiddles in IE7: jsfiddle.net/9uS4n/5 (fast) vs. jsfiddle.net/9uS4n/2 (slow). There appears to be at least a 1000 times improvement in performance using the join() technique.
–
Kirk WollJul 22 '11 at 17:57

Well, the post you linked to in your answer specifically tries to disprove the "myth" of Array.join which my answer suggests. So perhaps not. I merely posted what I've seen to be faster in practice.
–
RahulSep 21 '08 at 21:49

JavaScript doesn't have a native StringBuffer object, so I'm assuming this is from a library you are using, or a feature of an unusual host environment (i.e. not a browser).

I doubt a library (written in JS) would produce anything faster, although a native StringBuffer object might. The definitive answer can be found with a profiler (if you are running in a browser then Firebug will provide you with a profiler for the JS engine found in Firefox).

Traditionally StringBuffer is used over concatenation because the former has O(N) time complexity whereas the latter as O(N^2), thus the difference is significant for large N (but not for small N). In any case the O(N^2) scenario may not be the case in JavaScript depending on the environment in use.
–
locsterAug 30 '11 at 11:20

It is pretty easy to set up a quick benchmark and check out Javascript performance variations using jspref.com. Which probably wasn't around when this question was asked. But for people stumbling on this question they should take alook at the site.

The easier to read method saves humans perceptible amounts of time when looking at the code, whereas the "faster" method only wastes imperceptible and likely negligible amounts of time when people are browsing the page.

I know this post is lame, but I accidentally posted something entirely different thinking this was a different thread and I don't know how to delete posts. My bad...

As far I know, every concatenation implies a memory reallocation. So the problem is not the operator used to do it, the solution is to reduce the number of concatenations. For example do the concatenations outside of the iteration structures when you can.

This isn't actually bad advice, I don't know why it's voted down so much. I know it doesn't answer the specific question, but it deserves recognition as being generally good advice.
–
eyelidlessnessApr 24 '10 at 6:33

But for the small strings, this is irrelevant. You will only care about performances on very large strings. What's more, in most JS script, the bottle neck is rarely on the string manipulations since there is not enough of it.