...

View Full Version : Which of these two cases involving a variable would be faster?



Scriptdaemon
12-12-2006, 12:43 AM
I really didn't know how to explain what I am asking simply in the title, so forgive me for the ambiguous subject, but I am asking if either of these would be faster than the other?

Example:

var html = "<table>" +
"<tr>" +
"<td>";

vs.

var html = "<table>";
html += "<tr>";
html += "<td>";

A1ien51
12-12-2006, 03:37 AM
why don't you make up a test that does a bunch of them in a loop and seems what happens.

Eric

A1ien51
12-12-2006, 04:07 AM
I might actually do this test.... We will see if anything good is on tv...If not I guess I will have a blog entry..

lol

Eric

Scriptdaemon
12-12-2006, 07:02 AM
I did a small test, but as expected there was no noticeable difference. I figured since it wasn't too big of a change since it was a small example that there would be no real difference in speed, but I was just asking for the long run of things.

felgall
12-12-2006, 08:53 AM
The first one is shorter and so should be slightly faster for the page to load. The Javascript commands are the same so that probably wont make any difference.

liorean
12-12-2006, 11:02 AM
It's all dependent on which scripting engine is used and how that engine deals with string concatenations. If the engine is smart (SpiderMonkey), the byte code will be the same for those two examples. If the engine isn't (JScript), the byte code for the latter will have to look up the html variable each time. In both cases, the engine will have to create a lot of intermediaries that are later thrown away.
However, if the engine is really smart, it will use a string builder facility internally, so it doesn't produce as many intermediaries.

If you want to make string concatenation fast, you should do it like this instead:
var
html=[
'<table>',
'<tr>',
'<td>'].join('');Of course, speed for things like this is rarely an issue unless you're adding LOTS of small strings together. With just three like in this case, it will hardly make any difference.

A1ien51
12-12-2006, 01:55 PM
Well you lost out to a broken pipe under my sink. I ran a small test and got some surpries with speed differences in IE and Firefox and Opera. (I also did the join because there was a talk about that here in the past.) Hopefully I can get my findings in a readable format.

Eric

Scriptdaemon
12-12-2006, 04:08 PM
Thanks, liorean.

I will also await your findings too, when you get the chance.

liorean
12-12-2006, 06:43 PM
Well, I did some testing, a very artificial and contrived test (http://testsuite.liorean.net/stringconcatenationperformance.html).

The results from Opera 9.03.8675 were as follows:
true
array joining: 610
true
string concat: 500
true
+ operator with vars: 1140
true
+ operator: 938
true
+= operator: 1110Evidently, strings using the concat method were fastest here. The program grew in memory by about 11MiB when loading the page, and didn't drop in size after finishing.


The results from Firefox 2.0 were as follows:
true
array joining: 3657
true
string concat: 1063
true
+ operator with vars: 1078
true
+ operator: 0
true
+= operator: 1484Firefox surprised me by the lousy performance for array joining. The + operator is clearly exceptional here - SpiderMonkey clearly does some compiler optimisations and constant folding, which makes that test blazingly fast. However, I would expect that to only apply for cases where ALL the strings added together are compile time constants. (That's how JScript.NET behaves, from what I've been told.) The browser memory grew some 50MiB in size while computing, settling at a final size of about 10MiB larger.




Internet Explorer 6.0 clearly has problems with strings. Running that program, it continuously grew by about 500MiB, then shrunk to 50MiB, then grew and so on ad infinitum. I changed the test to make just a single iteration instead of one hundred iterations for ie and tried again. It still grew by about 500MiB while calculating, but it settled down at about 17MiB above original size.
true
array joining: 47
true
string concat: 1094
true
+ operator with vars: 1453
true
+ operator: 1125
true
+= operator: 4625Note that these numbers come from doing ONE SINGLE iteration, NOT ONE HUNDRED iterations like the other browser tests!
The efficiency of doing join on arrays is just massive compared to the other methods. And since ie6 needs by several orders of magnitude more time to do string concatenation than the other browsers, I think the won from using array joining is evident.


Swift 0.2 (WebKit on Win32)
true
array joinin: 547
true
string concat: 468
true
+ operator with vars: 8078
true
+ operator: 10782
true
+= operator: 5984Again, string concatenation is fastest followed by array joining. Since this is WebKit, Safari on Mac OS X should exhibit similar performance.






CONCLUSION:
concat is generally the best way to build strings. Except for one thing: Internet Explorer/JScript has absolutely abyssal performance for all but one method of building strings - array joining. Now, array joining is the slowest way to build a string in Firefox/SpiderMonkey, but on the other hand the performance isn't even nearly as bad as Internet Explorer using any of the other ways of building the string.

What's worth more, a hundred times better performance in Internet Explorer, which has the absolutely worst performance of the tested browsers; or three times better performance in Firefox?

liorean
12-12-2006, 09:19 PM
Some stats from Safari 1.3 from my 900MHz G3 iBook as well:
true
array joining: 1417
true
string concat: 2973
true
+ operator with vars: 60987
true
+ operator: 64147
true
+= operator: 15844

A1ien51
12-12-2006, 09:21 PM
I found about the same thing, IE would freeze in tests I ran that the others would fly through. Opera had some good numbers also.

Eric



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum