Skip navigation.


Yea.. nice example Chris, maybe next you'll be right!

Bad Architecture

There's this nagging voice in the back of my head that says, "don't make fun of the readers! They anger easy and won't come back". However, I couldn't resist reponding to Chris's post about using arrays to create strings because it's faster than concatenation!

So this is today's WTF:

You do realize that cating strings is slower than manipulating arrays, right?
// meh...
/* -->8-- */
// update the area code
$stSQL .= "$areacode=$codeData, ";

// update the phone num
$stSQL .= "$phonenum='$phoneData' ,";
/* -->8-- */

// yay!
/* -->8-- */
// update the area code
$update_array[] = "$areacode=$codeData";

// update the phone num
$update_array[] = "$phonenum='$phoneData'";

$query = "UPDATE tablename SET " . implode(', ', $update_array) ....;
/* -->8-- */

And of course, you should always be checking to see if a variable actually exists, rather than simply assuming it will be there (*cough*$_POST[$areacode]*cough*). I hope this is just an oversight while making an example of poor code.

But from this little shell script we find that string concatenation is more than twice as fast than using arrays.

Run Number #1
1199999 - bigString, Time: 0.5843870639801
1199999 - bigString2, Time: 1.0092749595642
Run Number #2
1199999 - bigString, Time: 0.34683203697205
1199999 - bigString2, Time: 1.0810549259186
Run Number #3
1199999 - bigString, Time: 0.35090112686157
1199999 - bigString2, Time: 1.0080449581146

Well if you look at the shell script code you'll see I do 100,000 iterations. But if you only do like 20 iterations using an array is actually faster, take a look:

239 - bigString, Time: 0.0015630722045898
239 - bigString2, Time: 0.0010149478912354

Only after about 150 iterations does string concatenation become faster than using an array. See:

1799 - bigString, Time: 0.0024600028991699
1799 - bigString2, Time: 0.0025348663330078

So yea he's right, but then again, who the hell cares about those thousandths of a second? At least I'll be right when generating SQL for tables with more than a few hundred columns! ;b