Question about for() loop

[nrg_alpha]

Ok.. I recently stumbled upon a for() loop code snippet that looked something like this:

$str = array(12, 34, 45, 65, 22, 7, 21, 56, 78, 99, 87, 67);
for($i =0, $numKeys = count($str); $i < $numKeys; $i++){
   echo 'The value in key number ' . $i . 'is ' . $str[$i] . '<br />';
}

Now I noticed the introduction of a second variable '$numKeys' which is assigned the count of the array $str. I found this odd, as I am so used to seeing:

for($i =0, $i < count($str); $i++){

Obviously, I'm asking myself why...
The immediate thought that came to mind for the reasoning behind the for() line in the first example was that perhaps the $numKeys variable is introduced and assigned the count of the array $str so that in each loop iteration, there is no need to keep checking againts the count() function (or is that a language construct?.. I digress). As a result, less processing is involved, because the $i variable is now always checked against the predefined variable $numKeys, which was set only once and thereby speeds things up.

Do I understand this correctly? If so, this leads to a second question.. The example array above is obviously quite simplistic. But if I am correct in my assumption that the first snippet is to save on count() calculations per loop iteration, at which point would one need to employ this method? I mean, would that method be considered better once an array exceeds a certain size? On small arrays, I suppose there is no need to introduce that second variable for count() assignation ($numKeys)?

Cheers,

NRG

[laserlight]

Yes, your understanding is correct.

But if I am correct in my assumption that the first snippet is to save on count() calculations per loop iteration, at which point would one need to employ this method? I mean, would that method be considered better once an array exceeds a certain size? On small arrays, I suppose there is no need to introduce that second variable for count() assignation ($numKeys)?

As far as I can tell with experiments in the past, the only penalty from count() is the function call, so it does not matter if the array is large or small. It probably also does not matter much if you call it on each iteration or if you store its return value in a variable.

[nrg_alpha]

Ok, thanks for clarifying this.. just not used to seeing for() loops written in such a manner.

Cheers,

NRG

[NogDog]

Of course, it would be much simpler to just do:

foreach($str as $i => $value){
   echo 'The value in key number ' . $i . 'is ' . $value . '<br />';
}

🙂

[nrg_alpha]

Nog, yes, I realise that. 😉 I even go simpler still as a rule:

foreach($str as $val){

This is when I'm only interested in the keys' values, not so much the keys themselves as well as their values.

I was just reading a chapter on arrays and there was a comparative demonstration of using foreach() as well as for().. so when I came across the for(), I was kind of thrown off by that second variable.

I always tend to use foreach() myself.. feels more 'streamlined'.

[NogDog]

The original example is probably a bit more efficient, since it only has to call count() once; which I'm sure is why the original author did it that way.

Just FYI, you can have multiple statements in the final arg, too, plus complex comparisons in the 2nd arg, allowing for potentially quite complex for statements, e.g.:

for($x=0, $y=99; $x < 100 && $x <= $y; $x++, $y--) {

[nrg_alpha]

NogDog;10882340 wrote:

Just FYI, you can have multiple statements in the final arg, too, plus complex comparisons in the 2nd arg, allowing for potentially quite complex for statements, e.g.:

for($x=0, $y=99; $x < 100 && $x <= $y; $x++, $y--) {

Yeah, I kind of realised that afterwards... I suppose so long as you know to separate arguments with commas and only use the semi-colon delimiter to switch gears to the next segment of the for() statment, you can build quite a few of statments...

[Weedpacket]

$array = array('foo');

for($d=0; $d<30; ++$d)
{
	echo "Step ".$d.": Timing for an array of length ".count($array)."\n";
	echo "\t Recalculating count(): ";
		$p=0;
		$start = microtime(true);
		for($t=0; $t<count($array); ++$t)
		{
			++$p; // Just something to do.
		}
		$delta_re = microtime(true)-$start;
		echo $delta_re." seconds\n";
	echo "\tPrecalculating count(): ";
		$p=0;
		$start = microtime(true);
		for($t=0, $tt=count($array); $t<$tt; ++$t)
		{
			++$p; // Just something to do.
		}
		$delta_pre = microtime(true)-$start;
		echo $delta_pre." seconds\n";
	echo "\t\tRatio: ".($delta_re/$delta_pre)."\n\n";
	$array = array_merge($array, $array);
}

[nrg_alpha]

Well, Mr.Packet's code sample brought to light something I didn't quite get right. Before I explain further...Weedpacket, I had to comment out this line.

$array = array_merge($array, $array);

My browser would seem to hang for a second, then go blank, and that was it. Nothing more (tested in Firefox 3.0.1 and Opera 9.51).

So with that aspect commented out, the snippet executes and sheds some additional light: even with the array being not so much the issue (due to being commented out), the number of cycles (loops) in conjunction to what goes on inside those loops definatelty matters (the heavier both factors become, I suspect the greater the discrepencies between for() methods becomes).

In anycase, it ran with interesting results..

Step 0: Timing for an array of length 1 Recalculating count(): 2.0980834960938E-5 seconds Precalculating count(): 1.1920928955078E-5 seconds Ratio: 1.76

but when I examine some of the steps (sometimes after refreshing (F5)), it seems the precalculated count is worse than the recalculated one:

Step 6: Timing for an array of length 1 Recalculating count(): 1.215934753418E-5 seconds Precalculating count(): 9.0599060058594E-6 seconds Ratio: 1.3421052631579

Is this a display error? Rounding off error? In either case, overall the results are pretty revealing (even with a small cycle (30 steps), and what goes on within those cycles (++p) and all this despite the array_merge causing issues.

Cheers,

NRG

Perhaps the effects would have been even further demonstrated had the array_merge function come into play?

[Weedpacket]

nrg_alpha wrote:

My browser would seem to hang for a second, then go blank, and that was it. Nothing more (tested in Firefox 3.0.1 and Opera 9.51).

Ah, you're doing it through a web server, and therefore there'll be buffering and timeouts and so on. I was doing it from the command line (hence the absence of any HTML). You might want to reduce $d from 30 down to say 20 or so, and add the HTML formatting (or just run the script as given at the command line 🙂). The results would then be much more illuminating.

Recalculating count(): 1.215934753418E-5 seconds
Precalculating count(): 9.0599060058594E-6 seconds
Ratio: 1.3421052631579

Is this a display error? Rounding off error?

Er, have another look at the exponents: 9.06e-6 is less than 1.22e-5 (the latter is 1.34 times larger) 😉

[laserlight]

So with that aspect commented out, the snippet executes and sheds some additional light: even with the array being not so much the issue (due to being commented out), the number of cycles (loops) in conjunction to what goes on inside those loops definatelty matters (the heavier both factors become, I suspect the greater the discrepencies between for() methods becomes).

Actually, the more work the loop body actually does, the closer the relative timing ratio should tend to 1, since the actual work would outweigh the cost of count(). This is why I say that it probably does not matter much if you call count() on each iteration or if you store its return value in a variable, but of course avoiding the function call almost always makes things faster.

[nrg_alpha]

Weedpacket;10882389 wrote:

Ah, you're doing it through a web server, and therefore there'll be buffering and timeouts and so on. I was doing it from the command line (hence the absence of any HTML).

Ok.. Managed to run it from CLI. Much better! 🙂 So now with the array_merge(), it becomes more apparent.

Weedpacket;10882389 wrote:

Er, have another look at the exponents: 9.06e-6 is less than 1.22e-5 (the latter is 1.34 times larger) 😉

Either my math is horrible (which is a huge possibility!!), or I am simply misunderstanding something.. isn't 9.06 to the power of 6 larger than 1.22 to the power of 5?

[laserlight]

Either my math is horrible (which is a huge possibility!!), or I am simply misunderstanding something.. isn't 9.06 to the power of 6 larger than 1.22 to the power of 5?

9.06 times (10 to the power of -6) is less than 1.22 times (10 to the power of -5).

[nrg_alpha]

laserlight;10882396 wrote:

Actually, the more work the loop body actually does, the closer the relative timing ratio should tend to 1, since the actual work would outweigh the cost of count(). This is why I say that it probably does not matter much if you call count() on each iteration or if you store its return value in a variable, but of course avoiding the function call almost always makes things faster.

Yes, this makes more sense.. I think my logic is flawed 🙁
(what else is new?)

[nrg_alpha]

laserlight;10882398 wrote:

9.06 times (10 to the power of -6) is less than 1.22 times (10 to the power of -5).

Oh, I thought it was 9.06 exponent dash 6.. not minus 6.

[Weedpacket]

laserlight wrote:

This is why I say that it probably does not matter much if you call count() on each iteration or if you store its return value in a variable, but of course avoiding the function call almost always makes things faster.

Yes, but if you have the function call in the iteration test, it's called on every iteration; in the initialiser it's only called once at the start of the loop. n calls to a function will pretty much always be slower than 1 call to the function for n>1.

If count() could cache its result for a given array and return the cached result when called, that would save a bit (though not the cost of the call itself), but in general it can't because for all it knows the array has changed size in the meantime or might otherwise not be the same array any more (else why would you need to count its values again?).

[laserlight]

Weedpacket wrote:

Yes, but if you have the function call in the iteration test, it's called on every iteration; in the initialiser it's only called once at the start of the loop. n calls to a function will pretty much always be slower than 1 call to the function for n>1.

That is what I said: avoiding the function call almost always makes things faster.

EDIT:

Weedpacket wrote:

If count() could cache its result for a given array and return the cached result when called, that would save a bit (though not the cost of the call itself), but in general it can't because for all it knows the array has changed size in the meantime or might otherwise not be the same array any more (else why would you need to count its values again?).

So you think that count() performs a linear time count of the array instead of a lookup? I thought otherwise (but admittedly have never read the PHP source itself), though I may have been misled since such a count would not be done in PHP, so the bulk of the timing would have come from the PHP benchmarking code setup and the count() function call overhead instead of the actual count() work. This could explain why count() is so very slightly slower on larger arrays.

[Weedpacket]

laserlight wrote:

So you think that count() performs a linear time count of the array instead of a lookup?

No, the size of the array is a part of the array structure (hang on, I'll just go double check....yep; HashTable->nNumOfElements), but it does need to be looked at on every iteration - as well as checking to see if the argument is in fact an array, whether a deep count is required or not, and checking that the HashTable involved is in a consistent state.

laserlight wrote:

This could explain why count() is so very slightly slower on larger arrays.

In my test code (where the only difference between benchmarking code is the location of the count() call), on my machine™, putting the call to count() in the iteration expression instead of the initialiser causes the loop to become about eight times slower (consistently, once the size of the array gets above a hundred or so). Significantly different from one. 🙂

[laserlight]

Weedpacket wrote:

In my test code (where the only difference between benchmarking code is the location of the count() call), on my machine™, by a factor of around 8 (consistently, once the size of the array gets above a hundred or so).

What exactly are you comparing when you state such a factor? I am comparing the difference between a single count() on a small array and a single count() on a large array when I say that "count() is so very slightly slower on larger arrays".

EDIT:
Oh, you are comparing the difference between caching and otherwise. The problem is, you are ignoring the actual work done in the loop: clearly, a comparison between the two versions where the loop body is trivial would result in a significant difference between the two, since the count() call would dominate. My point from the beginning is that this is actually insignificant in the overall picture. Of course, since caching is rather easy to perform and does not obfuscate the code, it is probably better to do it anyway.

[Weedpacket]

See the posted code 🙂. I'm comparing what nrg_alpha was asking about: using count() inside the initialiser versus count() in the iteration clause (see the posted code). Obviously, if the body of the loop changes the proportion of the total run time spent within it will change, but generally speaking it's the size of the input that varies, not the size of the program the input is being run through (bigger apples versus smaller apples, rather than <insert cliché here>.) If the body is to change it ought to be to something functionally equivalent. But then you're not comparing the difference between having count() in the initialiser versus count() in the iteration any more, you're comparing the different implementations of the body. Hence some confusion (especially when you're simultaneously talking about the size of the array).