[PHP] function performance test (lees dit!)

[GiLuX]

dit is best interessante info voor iedereen die serieus php gebruikt.

ik kwam via de zend forums op deze pagia terecht:
http://phpxpath.sourceforge.net/benchmark/phpBench.php

zoals je hier kan zien blijkt dat het pre-counten van een van je 'for' loop zo'n 70 keer sneller is dan het niet doen,
of ik moet eigenlijk zeggen dat door het niet pre-counten je for loop 70 keer langzamer is.

code:

Test:
For-loop test 
Is it worth the effort to calculate the length of the loop in advance? 
E.g. "for ($i=0; $i<$size; $i++)" instead of "for ($i=0; $i<sizeOf($x); $i++)" 
+  100 % 1: With pre calc Total time:   13[ms] 
+ 6752 % 2: Without pre calc Total time:  896[ms] 
Conclusion:
The test above speeks for it self. Always calculate the length of the loop in advance!

echt heel wierd.

er staan nog een paar van die rare gevallen bij.


als je dit gezien hebt ga je waarschijnlijk een stuk beter op je code letten.

[jelmervos]

Vreemd, hieruit maak ik op dat PHP bij elke keer de for lus doorlopen die waarde opnieuw berekend, toch?

[mbravenboer]

Lijkt mij toch logisch? Als een onderdeel van de conditie in een while of for-loop nooit verandert is het altijd beter om die van te voren uit te rekenen.

Bij elke loop wordt anders immers die waarde opnieuw uitgerekend. Een goede compiler zou dit er makkelijk uit kunnen optimaliseren door de de berekening omhoog te liften, maar soms is er niet te garanderen dat die waarde ook echt constant is tijdens de loop-constructie (wat gebeurt er bijvoorbeeld als je de variabele een nieuwe waarde geeft ).

[spine]

HANDIG! THNX
ik ga nu heel goed opletten!

[Verwijderd]

Op donderdag 20 december 2001 23:37 schreef jelmervos het volgende:
Vreemd, hieruit maak ik op dat PHP bij elke keer de for lus doorlopen die waarde opnieuw berekend, toch?

Lijkt me logisch dat hij telkens als de lus doorlopen wordt $size gaat berekenen, hij moet toch kijken of die conditie klopt?
Als je zegt:
a < 3 + 5;
dan gaat hij elke keer als hij aan het begin van de lus is 3 bij 5 optellen. Doet hij bij een while ook he, alleen dan staat de conditie in de lus zelf, en niet in de lusaanroep zelf

edit:
shit mbravenboer was me voor

[23m3]

Mja, logisch is het wel.. vooral omdat het PHP geinterpreteerd wordt... in C++ maakt het bijvoorbeeld niet zoveel uit want de compiler optimaliseerd automatisch een hoop voor je

[mbravenboer]

doniek: Als je zegt:
a < 3 + 5; dan gaat hij elke keer als hij aan het begin van de lus is 3 bij 5 optellen.

De meeste simplistische systemen ondersteunen toch wel constant folding, dus ik neem aan dat dit toch
wel a < 8 wordt .

shit mbravenboer was me voor

Sorry .

[Verwijderd]

Op donderdag 20 december 2001 23:44 schreef mbravenboer het volgende:

De meeste simplistische systemen ondersteunen toch wel constant folding, dus ik neem aan dat dit toch
wel a < 8 wordt .

Ik dacht ik leg het eens een keer simpel uit, zodat ik het zelf nog kan begrijpen . Maar het idee was toch wel duidelijk??

Op donderdag 20 december 2001 23:44 schreef mbravenboer het volgende:

Sorry .

Maakt niets uit, ik ben niet meer zo snel op dit tijdstip en moet zachtjes typen anders kunnen me ouwe lui niet slapen

[Verwijderd]

Op donderdag 20 december 2001 23:33 schreef GiLuX het volgende:

code:

Test:
For-loop test 
Is it worth the effort to calculate the length of the loop in advance? 
E.g. "for ($i=0; $i<$size; $i++)" instead of "for ($i=0; $i<sizeOf($x); $i++)" 
+  100 % 1: With pre calc Total time:   13[ms] 
+ 6752 % 2: Without pre calc Total time:  896[ms] 
Conclusion:
The test above speeks for it self. Always calculate the length of the loop in advance!

echt heel wierd.

Weird ? Helemaal niet... ligt in hoofdzaak aan de compiler of parser, maar grof genomen is het altijd beter een waarde die toch vast blijft, op voorhand te berekenen.

Ikzelf heb een vooral een assembler background, en in assembler reken je normaal *altijd* de voorwaardes voor loops op voorhand uit, en *nooit* elke keer tijdens loop.

Als je zeker wil zijn dat het steeds optimaal gebeurd, en je niet wil afhangen van de goodwill van de compiler, reken ze gewoon zelf uit op voorhand

[mbravenboer]

doniek: Ik dacht ik leg het eens een keer simpel uit, zodat ik het zelf nog kan begrijpen . Maar het idee was toch wel duidelijk??

Ja hoor . Het was alleen sprekender geweest met iets wat niet constant is .

moet zachtjes typen anders kunnen me ouwe lui niet slapen

Hehe . Dat had ik vroeger ook .

[GiLuX]

idd,
dat met die for loop is eigenlijk best logisch zoals bravenboer (e.a.) het uitlegd, maar was het niet zo dat php runtime de pagina compiled en dan pas uitvoerd?

en staat er ook nog die issue over 'foreach' en 'each'.
heeft allemaal iets te maken hoe php met objecten omgaat,
heel vaag, php maakt bij elke instance een copie en niet een reference, maar gaat er eigenlijk pas echt een copie van maken als je er iets aan veranderd.

krijg je allemaal rare effecten van.

word gelukkig in zend2 allemaal overboord gezet en omgevormd naar het java model

[paulh]

Daar kwam ik 2 dagen geleden ook zelf achter.

Ik had een for-loopje waar bij ik controleerde op de lengte van een array ... maar in datzelfde loopje werd de array ook nog eens aangevuld. Dus werd het een oneindige loop.

[Verwijderd]

Ik gebruik heel regelmatig dit soort constructies:

PHP:

<?
for($i=0;$i<count($x);$i++) { loop }
?>

Dan zou ik dus ook beter gewoon

PHP:

<?
$a = count($x);
for($i=0;$a;$i++) { loop }
?>

kunnen doen, als ik dit goed begrijp.
Lijkt me BTW een beetje onlogisch, want count($x) is natuurlijk een constante. Die worden dus niet gecached? Of wordt iedere loop als een nieuwe gezien?

[Johannes]

Op vrijdag 21 december 2001 10:26 schreef daniel_hoenderdos het volgende:
Ik gebruik heel regelmatig dit soort constructies:

PHP:

<?
for($i=0;$i<count($x);$i++) { loop }
?>

Dan zou ik dus ook beter gewoon

PHP:

<?
$a = count($x);
for($i=0;$a;$i++) { loop }
?>

kunnen doen, als ik dit goed begrijp.
Lijkt me BTW een beetje onlogisch, want count($x) is natuurlijk een constante. Die worden dus niet gecached? Of wordt iedere loop als een nieuwe gezien?

count($x) is geen constante, want je zou $x kunnen veranderen in je loop, daarom moet het elke keer weer berekend worden, zoals hierboven al eerder uitgelegd.

[Burat]

Mooi, nog net op tijd om in onze programmeer conventies van 2002 op te nemen

[Nielsz]

Yep, logisch.
Daar let ik al op

[paulh]

Op vrijdag 21 december 2001 10:26 schreef daniel_hoenderdos het volgende:
Lijkt me BTW een beetje onlogisch, want count($x) is natuurlijk een constante. Die worden dus niet gecached? Of wordt iedere loop als een nieuwe gezien?

Dat is nou net wat ik uitlegde in mijn post boven de jouwe. Als je $x aanvult met extra waarden binnen je loop wordt deze oneindig.

[mbravenboer]

daniel_hoenderdos: Die worden dus niet gecached? Of wordt iedere loop als een nieuwe gezien?

In een imperatieve taal is 'caching' vrijwel onmogelijk.

In heel veel gevallen is het niet mogelijk om aan te geven of een variabele ook echt constant is of niet. In ieder geval kost het erg veel tijd en analyse om dit uit te zoeken.

Het is dus echt niet zo dat at-runtime in een geinterpreteerde taal even van alles uitgezocht gaat worden over 'caching'. Dit is meer werk voor een wat betere compiler .

[ACM]

* ACM heeft net een php-projectje van meer dan 4000 regels code gechecked

Maar 4 van die "niet precalc" for-loops, en geen van die slome foreach($array as $key => $var)

[mbravenboer]

Netjes .

Overigens heeft het procentueel gezien alleen een groot effect als de loop-body zelf weinig tijd kost. Als de loop groter is, heeft het procentueel gezien minder nut om de waarde van te voren uit te rekenen: de winst is constant bij hetzelfde aantal-loops.

[chem]

Op vrijdag 21 december 2001 16:01 schreef ACM het volgende:
* ACM heeft net een php-projectje van meer dan 4000 regels code gechecked

Maar 4 van die "niet precalc" for-loops, en geen van die slome foreach($array as $key => $var)

is er een snellere variant voor de foreach() dan?

Zal zo eens testjes doen...

[Nielsz]

Op vrijdag 21 december 2001 16:01 schreef ACM het volgende:
Maar 4 van die "niet precalc" for-loops, en geen van die slome foreach($array as $key => $var)

Hmmmz die gebruik ik wel. Een andere snellere manier daarvoor aanwezig?


[ Toch eens beter opletten Damn Chem ]

[ACM]

Op vrijdag 21 december 2001 16:04 schreef mbravenboer het volgende:
Overigens heeft het procentueel gezien alleen een groot effect als de loop-body zelf weinig tijd kost. Als de loop groter is, heeft het procentueel gezien minder nut om de waarde van te voren uit te rekenen: de winst is constant bij hetzelfde aantal-loops.

Loop-bodies waren allemaal (alle 4 ) dingen als "for(...) echo '...';" en dat eventueel iets complexer

(voornamelijk tables afdrukken dus)

Op vrijdag 21 december 2001 16:14 schreef chem het volgende:
is er een snellere variant voor de foreach() dan?

Zal zo eens testjes doen...

Op vrijdag 21 december 2001 16:23 schreef Nielsz het volgende:
Hmmmz die gebruik ik wel. Een andere snellere manier daarvoor aanwezig?

Volgens die test van boven wel...

Maar dat zal afhangen van de situatie (met een standaard forloop die dus zowel array_keys- als array_vals-waarden afloopt)

[edit]
Na een refresh veranderd het wel heel sterk
Valt dus wel mee, ik had gewoon een "slechte run".

[chem]

mijn testje:

WHILE generated in 3.395 seconds

FOREACH K => V generated in 1.441 seconds

FOREACH V generated in 1.28 seconds

FOR generated in 1.622 seconds

bij een array van 100,000 entries.

PHP:

<?
for($i=0;$i<100000;$i++) {
    $array[] = rand(1,10000);
}

while (list($k, $v) = each ($array)) {
    ;
}

foreach($array as $k => $v) {
    ;
}

foreach($array as $v) {
    ;
}

$val = sizeof($array);
for($i=0;$i<$val;$i++) {
    $array[(int)$i];
}
?>

[chem]

meeste code verbaast me niet dat het sneller is. Wel interessant vond ik dat een === sneller is dan een ==, dus dat ga ik zo ff doorlopen

[drm]

Op vrijdag 21 december 2001 16:38 schreef chem het volgende:
meeste code verbaast me niet dat het sneller is. Wel interessant vond ik dat een === sneller is dan een ==, dus dat ga ik zo ff doorlopen

Dat is opzich niet zo gek. Bij een == wordt er namelijk impliciet typecasting toegepast voor alle mogelijk typen.
^{zo is "00" == 0 waar, maar "00" === 0 niet.}
En dat kost natuurlijk tijd