Take the 2-minute tour ×
Code Review Stack Exchange is a question and answer site for peer programmer code reviews. It's 100% free, no registration required.

I form DOM nodes as strings and append them to DOM tree like below using jquery.

var dom = '<div><div style="display: inline-block">first name</div>'
             '<div style="display: inline-block">last name</div></div>';

$("#contacts").append(dom);

above code is a small sample. In most of my cases dom will hold big strings.

When i recently read about JS performance tutorials, i saw this POST.

They told, this way of string concatenation is not a good practice. They told to use .join() instead of concatenation. But that seems like old post. Which one is efficient in these days?

Thanks!!!!

share|improve this question
    
this used to be the case, but these days they are saying concatenation is faster than join now. –  chovy Dec 16 '12 at 7:38

3 Answers 3

up vote 12 down vote accepted

Strings are immutable. It means that when you allocate memory while creating a string, you are not able to reallocate it. So, this code:

var a = 'a';
a = a + 'bc';

Will allocate a new block of memory for 'a' variable, instead of reusing already allocated.

When you do something like 'a' + 'b' + 'c' + 'd' each concatenation allocates a new block of memory for every temporary string.

When you use something like this:

var a = 'a';
a = [a, 'b', 'c'].join('');

join function calculates memory for result string and allocates it only once for a complete string.

As it is shown in the post that you mentioned, it is easier to handle and to avoid memory leaks in JS interpreter (it seems that IE6 and IE7 just not handle garbage collection for the first variant correctly).

If you are interested for the speed of string concatenation for different browsers you can try and view it here.

UPD: Not advocating join, just trying to explain why it was assumed as an optimized variant. As seen at jsPerf tests new browsers optimize string concatenation, so it is faster.

share|improve this answer
2  
+1 for the updated note about how join isn't necessarily the best way to go with new browsers. Just ran the jsPerf test for Chrome 23.0.1271.95 and join was actually the slowest option. –  Agent_9191 Dec 11 '12 at 12:43
1  
Likewise in Firefox 12, join is quite a bit slower than any of the other options. –  Izkata Dec 11 '12 at 12:51
    
I do think there is some notion of size that needs to be considered, though. If one were to required to build a very large string incrementally over wildly varying code paths, at some point, pushing to a dynamic array (with reasonable growth rate implementation, which I assume most js. imps. have) and joining is always going to be faster than always conjoining. Suppose you have a string that's 10K characters long, and you want to create a new string appending 50 strings (10 characters each) to it. One way creates one 10K+500 characters at once, the other creates fifty 10K+ strings. –  JayC Dec 11 '12 at 17:44

Considering this jsperf, I would stick to

var a = "asd" + "Foo" + "bAr";
share|improve this answer
    
The referenced test uses static strings which allows the JS engine to optimize the direct concatenation essentially into a NoOp. I tried to fix this to get results that are a bit more realistic: jsperf.com/string-concatenation/34 (Now Array.join wins on Firefox) –  x4u Dec 11 '12 at 15:54

Since it appears that you're working with the DOM you might want to think about using HTML fragments rather than strings.

Here is one article on the subject: http://ejohn.org/blog/dom-documentfragments/

For your example, try using something like

$("<div />").css("display","inline-block").html("first Name");

Another related question on using fragments vs. strings: http://stackoverflow.com/questions/2217409/jquery-best-practice-for-creating-complex-html-fragments

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.