Javascript String Concatenations

[psimakov]

I just read a great article by Dave Johnson on comparative performance
of XML and JSON parsing. It is a very important for anyone doing AJAX.

But the parsing is not the only place where CPU can be wasted. I
personally consider String Concatenations to be even bigger evil.

Here is test study that shows dramatic performance impact of String
Concatenations and how to avoid it.

http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=JavascriptStringConcatenation

 

[Lasse Reichstein Nielsen]

Here is test study that shows dramatic performance impact of String
Concatenations and how to avoid it.

http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=JavascriptStringConcatenation

The author hints at the better solution, but doesn't elaborate.
In Javascript, a simple array can take the place of the Java StringBuffer,
so each "append" is a "push" and the "toString" is "join", i.e.,

var buf = [];
for(...long loop...) {
buf.push("string to append");
}
... buf.join("");

You can also try to hide this in a StringBuffer-like object:
---
function StringBuffer() {
this.buffer = [];
}
StringBuffer.prototype.append = function append(string) {
this.buffer.push(string);
return this;
};
StringBuffer.prototype.toString = function toString() {
return this.buffer.join("");
};

alert(new StringBuffer().append("hello ").append("world"));
---

It is so simple that there is no reason *not* to go for the general
solution instead of the stopgap measure of intermediate buffers
(ofcourse, if you know the size of your data, you can check that
intermediate buffers will do, but the time complexity is still
quadratic in the size of the outer loop - it's just the constant
that got smaller).

/L

 

[web.dev]

I just read a great article by Dave Johnson on comparative performance
of XML and JSON parsing. It is a very important for anyone doing AJAX.

But the parsing is not the only place where CPU can be wasted. I
personally consider String Concatenations to be even bigger evil.

Here is test study that shows dramatic performance impact of String
Concatenations and how to avoid it.

http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=JavascriptStringConcatenation

I would argue that test study is not conclusive. True, string
concatenations can be slow, but how you use them will also affect
performance. In the test study show, you're building a table.
Obviously it would be slow. Have you considered other factors? The
code is no doubt inefficient. For example, it is using two for loops!
That's a O(n^2). Don't forget the initialization of a for loop. Oh
yeah, did you miss the post increment? Would be more efficient if it
was a pre-increment instead. Unless you have written an optimized
code, that study does not accurately show the performance impact of
string concatenations just because there are other factors that are
heavily weighed in (to me anyways).

 

[Lasse Reichstein Nielsen]

I would argue that test study is not conclusive. True, string
concatenations can be slow, but how you use them will also affect
performance. In the test study show, you're building a table.
Obviously it would be slow.

Why would it be slower than some other string of similar length?

Have you considered other factors? The code is no doubt
inefficient.

Apart from the string contcatenation, there are nothing that really
makes a difference.

For example, it is using two for loops! That's a O(n^2).

Well, no. The table has COLS*ROWS cells. Whether in one loop or
two, you have to create that many td-elements. If anything, that
number should be your "n" for complexity analysis.

Don't forget the initialization of a for loop.

Yes, it has overhead, but it's negligable.
A coprehensive test would also do a run of the loop without any
content, to find the overhead of that, but it is linear in n,
and with O(n^2) time for string doing n string concatenations,
that's quickly ignorable.

Oh yeah, did you miss the post increment? Would be more efficient
if it was a pre-increment instead.

You have absolutely no way of knowing that. The interpreter can easily
optimize a post increment where the value isn't used into a simple
increment. And again, even if it doubles the time taken for the increment,
it is still only a constant factor.

Unless you have written an optimized code, that study does not
accurately show the performance impact of string concatenations just
because there are other factors that are heavily weighed in (to me
anyways).

It doesn't really matter whether the surrounding code is optimized,
as long as you time it independently and subtract that from the total.

/L

 

[zif]

web.dev wrote:
[...]

Unless you have written an optimized
code, that study does not accurately show the performance impact of
string concatenations just because there are other factors that are
heavily weighed in (to me anyways).

If the point is to test the performance of concatenation against some
other method, then the code for each block should be identical except
for the concatenation and its alternative.

It is the performance of the concatenation that is being tested, not the
surrounding code.

 

[RobG]

I just read a great article by Dave Johnson on comparative performance
of XML and JSON parsing. It is a very important for anyone doing AJAX.

But the parsing is not the only place where CPU can be wasted. I
personally consider String Concatenations to be even bigger evil.

Here is test study that shows dramatic performance impact of String
Concatenations and how to avoid it.

It also shows that some browsers don't have a problem with it.

http://www.softwaresecretweapons.com/jspwiki/Wiki.jsp?page=JavascriptStringConcatenation

I'm not sure that concatenation per se is tested at all. '+=' is a
compound assignment (ECMA spec section 11.13.2), it may well be that IE
has a less than optimal algorithm for evaluating it.

Regardless, IE's woeful performance is not reflected in other browsers.
Firefox will perform += concatenation just as fast as the suggested
array push/join alternative (whether implemented in a 'StringBuffer'
object or simply coded instead of += ).

Using += IE takes around 40 times longer than array push/join. Its
array push/join is on par with Firefox.