[PHP] include of require, print of echo?

[Gerwin]

Wat is het beste qua performance:

PHP:

<?print "Hello world";?>

of

PHP:

<?echo "Hello world";?>

en

PHP:

<?include "bestand.php";?>

of

PHP:

<?require "bestand.php";?>

[ACM]

Daar zijn al meerdere topics over geweest en meerdere sites die dat voor je bekeken hebben.

Zelf uitzoeken is ook nog een optie.

Ik gok alleen dat het antwoord op je vraag is: 'dat is niet boeiend, verschil is nihil'.

[Gerwin]

Ik heb een aantal topics via de search gevonden, en geprobeert het zelf te vinden, maar niet echt een konkreet antwoord gevonden. 'k Weet dat het verschil nihil is, maar toch ben ik nieuwsgierig wat nu ECHT het beste is?

[ACM]

Het is het beste om in zo'n geval te gebruiken wat je ligt.
echo en print verschillen _iets_ van elkaar, kijk naar die verschillen niet naar de uitvoertijd.

Zelfde geldt voor require en include.

[WouZz]

Op woensdag 19 juni 2002 23:02 schreef Gerwin het volgende:
Ik heb een aantal topics via de search gevonden, en geprobeert het zelf te vinden, maar niet echt een konkreet antwoord gevonden. 'k Weet dat het verschil nihil is, maar toch ben ik nieuwsgierig wat nu ECHT het beste is?

Uit dit topic blijkt dat dat per systeem/configuratie nogal kan verschillen.. Dus de conclusie blijft: probeer het uit..

Wat wel duidelijk is: in bijna alle gevallen is echo aanroepen met meerdere variabelen (iets) sneller dan echo aanroepen met één "ge-concatenate" string.

Dus bijvoorbeeld

PHP:

<?echo "string", $var, "string", function($var);?>

i.p.v

PHP:

<?echo "string" . $var . "string" . function($var);?>

[Soultaker]

'require' is stricter dan 'include'. Als er iets mis gaat met includen, wordt de rest van het script uitgevoerd (al zal er wel een foutmelding gegeven worden). Bij 'require' wordt het script afgebroken. Dit kan heel af en toe een relevant verschil maken.

'print' accepteert precies één argument, terwijl 'echo' één of meer argumenten accepteert. Verder levert 'print' een return value op, waardoor 'print' wel te gebruiken is in expressies en 'echo' niet.

Ik wil het NIET over performance hebben in combinatie met welke constructie in PHP dan ook. Dank u. Als je geïnteresseerd bent in performance ga je maar C coden.

[WouZz]

Omdat ik het toch wél leuk vind om het over performance in PHP te hebben heb ik mijn benchmark script maar even geupdate...

_{Maar de resultaten variëren nogal per configuratie, dus download em ff en run em op je eigen server...}

[drm]

WouZz:
Omdat ik het toch wél leuk vind om het over performance in PHP te hebben heb ik mijn benchmark script maar even geupdate...

_{Maar de resultaten variëren nogal per configuratie, dus download em ff en run em op je eigen server...}

Ik dacht al, hoe kom je in vredesnaam aan 0.6 MB source voor een benchmarkje , maar toen bekeek ik de source, en zag ik dat je de complete HTTP 1.1 Header Definition erin had staan. Waarom weet ik niet, maar 't staat wel stoer, 0.6 MB source

zou je niet ff een leesbare versie erop kunnen zetten?

[Verwijderd]

Op donderdag 20 juni 2002 02:51 schreef WouZz het volgende:
Omdat ik het toch wél leuk vind om het over performance in PHP te hebben heb ik mijn benchmark script maar even geupdate...

_{Maar de resultaten variëren nogal per configuratie, dus download em ff en run em op je eigen server...}

Wel cuwl die benchmark, maar ik snap 1 ding niet echt.
1) <? ?>substring<? echo $var; ?>substring<? ?>
0.000901

2) <? ?>string<? ?>
0.000993

Hoe kan dat nou?
Het uitvoeren van 1) lijkt mij toch wel wat zwaarder (waarschijnlijk niet veel) zijn dan 2.
Bij 1) gebeurt bijna hetzelfde als bij 2) alleen wat meer tekst (2 maal substring ipv 1 maal string), de output van $var en nog een extra keer <? ?>.

lijkt erop dat als je met opzet extra variabelen op het scherm zet en nog wat extra tekst en een extra keer PHP aanroepen dat het sneller werkt.
Hoe kan dat nou?

[Grum]

kijk eens over watvoor tijden je et hebt .. misschien geeft je cpu een paar cycles aan een andere proces weg en is icm met et switchen tussen de processen de paar ns kwijt

[Verwijderd]

Op donderdag 20 juni 2002 12:22 schreef Grum het volgende:
kijk eens over watvoor tijden je et hebt .. misschien geeft je cpu een paar cycles aan een andere proces weg en is icm met et switchen tussen de processen de paar ns kwijt

Ik gebruik gewoon het benchmark script op de server van WouZz.

Heb het nog niet gedaan op eigen server (zal het ook niet gaan doen, ik zie hier ook wel wat de verschillen zijn)

Ik heb overigens meerdere keren geprobeerd en elke keer won 1 het van 2

[Verwijderd]

http://www.webgoeroe.net/?action=view&id=117

[Verwijderd]

Nette test op webgoeroe.net

Dit had ik overigens niet verwacht.
'32 bytes'. $var . '16 bytes' 0,86 ms
"32 bytes $var 16 bytes" 1,80 ms


Ik ga mŽn scripts maar een keer allemaal langs, volgens mij zal ik nog heeeeel wat aanpassingen moeten doen

[WouZz]

Op donderdag 20 juni 2002 09:19 schreef drm het volgende:

[..]

Ik dacht al, hoe kom je in vredesnaam aan 0.6 MB source voor een benchmarkje , maar toen bekeek ik de source, en zag ik dat je de complete HTTP 1.1 Header Definition erin had staan. Waarom weet ik niet, maar 't staat wel stoer, 0.6 MB source

zou je niet ff een leesbare versie erop kunnen zetten?

Nou, het hele verhaal begon dus hier met een aantal benchmarks. Maar de meeste benchmarks gebruikten x aantal loops om de tijdsverschillen duidelijk te maken. En om er zeker van te zijn dat PHP geen gebruik zou kunnen maken van eventuele 'caching' of interne optimalisatie (als die er zou zijn) voor loops, wou ik dus een benchmark zonder loops. En om toch nog een beetje significante verschillen te vinden heb ik maar een 103KB string gebruikt... En dat voor 21 tests maakt een script van ~2.2MB (gezipt 0.6)...

Hier en hier staat trouwens de sourcecode zo als ie nu ongeveer is..

[drGoeroe]

Hier vind je alles:

http://nl.php.net/print
http://nl.php.net/echo

http://nl.php.net/require
http://nl.php.net/include

[drm]

WouZz:
[snip]

hmja, zit wel wat in. Toch heb ik een soort reserve bij benchmarks in PHP... ik vetrouw ze sowieso niet helemaal, en zoals wel vaker geroepen, als je echt wil gaan milliseconde-neuken, dan kun je beter C ofzo gaan doen

_{How about een CGI in ASM?}

[D2k]

Op donderdag 20 juni 2002 15:07 schreef drm het volgende:
_{How about een CGI in ASM?}

je zou de source van eenin C geschreven Cgi kunnen optimaliseren als het goed is
maar das wel erg overdreven

[Soultaker]

Toch opmerkelijk dat ik hier nog nooit C/C++/Java benchmarks voorbij heb zien komen (of ik moet het vergeten zijn), terwijl ik al vaker dan ik heb kunnen tellen gezeur over PHP benchmarks gehoord.

Vooral het gezeur van echo statements is zo overbodig. Er komen misschien 100 echo statements in de executie van het gemiddelde script voor. Als dat per statement 1 ms kost, dan is het verschil nog verwaarloosbaar.

Een makkelijke programmeertaal moet je gebruiken omdat 'ie handig programmeert. Als je je vervolgens in allerlei vreemde bochten moet wringen om de efficiëntie te 'optimaliseren' (met enkele procenten) dan is het hele voordeel van de makkelijke taal weg. Ga dan gewoon C (of assembly, voor de masochisten onder ons) coden. Geheid een stuk sneller.

[Verwijderd]

Op donderdag 20 juni 2002 15:07 schreef drm het volgende:
_{How about een CGI in ASM?}

Ik zou dan eerder aan een apache module in assembly gaan denken, anders heb je die CGI overhead weer

[drm]

Soultaker:
(of assembly, voor de masochisten onder ons)

Toch ben ik het niet helemaal met je eens dat het onzin is het te onderzoeken. Stel dat je een keer een groot performanceverschil tegen komt...
Nu acht ik dat, net als jij toch wel onwaarschijnlijk en vaak verwaarloosbaar, maar toch... als je niet blijft onderzoeken, leer je nooit wat, toch?

Zef:
Ik zou dan eerder aan een apache module in assembly gaan denken, anders heb je die CGI overhead weer

ook goed punt

[WouZz]

Op donderdag 20 juni 2002 16:53 schreef Soultaker het volgende:
Toch opmerkelijk dat ik hier nog nooit C/C++/Java benchmarks voorbij heb zien komen (of ik moet het vergeten zijn), terwijl ik al vaker dan ik heb kunnen tellen gezeur over PHP benchmarks gehoord.

Vooral het gezeur van echo statements is zo overbodig. Er komen misschien 100 echo statements in de executie van het gemiddelde script voor. Als dat per statement 1 ms kost, dan is het verschil nog verwaarloosbaar.

Een makkelijke programmeertaal moet je gebruiken omdat 'ie handig programmeert. Als je je vervolgens in allerlei vreemde bochten moet wringen om de efficiëntie te 'optimaliseren' (met enkele procenten) dan is het hele voordeel van de makkelijke taal weg. Ga dan gewoon C (of assembly, voor de masochisten onder ons) coden. Geheid een stuk sneller.

Ook ik ben het niet met je eens dat het benchmarken van PHP statements overbodig is. Okay, voor veel (kleine) eenvoudige sites is het misschien onnodig om zulke kleine performance winsten te halen, omdat die in het niet vallen tegen de response- en downloadtijd.

Maar zodra je een grotere complexere site hebt kunnen dergelijke verschillen wel degelijk van belang zijn. Zo was ik laatst eens aan het spelen met microtime en zag ik dat mijn twee eregi's om email- en webadressen 'klikbaar' te maken de grote tijdvreters waren. Nadat ik deze had vervangen door een preg_replace was de response tijd van de pagina zichtbaar lager, zelfs bij niet al te grote stukken tekst.

En ik weet ook wel dat je soms door simpelweg een extra index in je database toe te voegen of door je query net even iets anders te schrijven een performance boost krijgt die vele malen groter is dan die je kreeg nadat je vier uur bezig bent geweest om bijvoorbeeld al je echo statements te veranderen. Maar zodra je van mening bent dat je database structuur en query's helemaal optimaal zijn, dan kan je soms nog net 'dat beetje extra' halen door naar je PHP code te kijken.

Bovendien kan 'snelle' code niet alleen voordelig voor je bezoekers zijn, het kan ook zijn voordelen hebben voor je webserver die het uiteindelijk makkelijker heeft. Dit geldt naar mijn idee helemaal als je een drukbezochte webserver of gewoon een webserver met weinig resources hebt omdat je bijvoorbeeld zoals ik op een gedeelde virtual server zit. Bovendien kunnen kleine snelheidsverschillen uiteindelijk een groter snelheidsvoordeel opleveren wanneer de bewuste code/constructie meerdere malen wordt aangeroepen, zoals bijvoorbeeld in loops.

En okay, ik geef toe, het checken of echo of print nou de snelste is en of echo "substring $var substring" sneller is dan echo 'substring' . $var . 'substring' is misschien wel een beetje mierenneukerij, en kan je beter kijken naar je regexes en manieren om loops te doorlopen. Maar het is toch ook wel interresant en leuk om uit te vinden wat nou écht de snelste manier is voor één van je meest gebruikte 'language constructs'.

Verder ben ik het wel met je eens dat je het jezelf niet te moeilijk moet maken om de állersnelste manier te vinden. Uiteindelijk moet je voor jezelf gewoon de juiste verhouding zien te vinden tussen lees- en onderhoudbaarheid van je code en snelheid. En over het algemeen weegt lees- en onderhoudbaarheid toch het zwaarst voor de meeste mensen. Maar waarom zou je een bepaalde manier gebruiken als het op een andere manier sneller is terwijl dat niet ten koste van je lees- en onderhoudbaarheid gaat? Want uiteindelijk wil iedereen toch de snelste code met de beste onderhoudbaarheid en eventueel flexibiliteit, toch?

En als je in PHP echt voor de uiterste maximum snelheid gaat (en niet wil overstappen naar C ) moet je geen gebruik maken van objecten en arrays, maar alles gewoon met functies en 'scalar' variabelen doen. En als je dan toch met arrays wilt werken gebruik dan vooral integers voor je indexes en geen strings... Maar zeg wel ff dag tegen je onderhoudbaarheid, leesbaarheid, flexibiliteit etc...

[Rense Klinkenberg]

Ik vind het zelf een beetje onzin om al je string assingments van "dit is een string" te gaan veranderen naar 'dit is een string' als daar ook tools voor zijn die dat at-runtime ook perfect kunnen doen. Een voorbeeld hiervan is de gratis zend optimiser. Ik kan me er zo over verbazen dat er maar zo weinig hosts dat ding hebben draaien, terwijl het een paar seconden werk kost en best wel wat performance winst kan opleveren voor slecht geprogrammeerde scripts.

Als je dan nog meer performance winst wil hebben, zou je een kunnen kijken naar de verschillende zend cache alternatieven die er zijn voor php, waarbij mijn voorkeur uitgaat naar de php-accelerator. Met zulke tools zijn tenminste echt zichtbare snelheidswinsten te behalen.

[HGM]

Op vrijdag 21 juni 2002 13:26 schreef freak007 het volgende:
Als je dan nog meer performance winst wil hebben, zou je een kunnen kijken naar de verschillende zend cache alternatieven die er zijn voor php, waarbij mijn voorkeur uitgaat naar de php-accelerator. Met zulke tools zijn tenminste echt zichtbare snelheidswinsten te behalen.

Die werkt ensich wel redelijk, maar er zitten nog wel een aantal wazige bugs in.
Gelukkig gaat bij de volgende release de registratietoestand eruit.

De meeste kwaliteitshosters hebben Zend Optimizer wel draaien. Helaas is de Optimizer ook niet voor alle systemen beschikbaar.

[pietje63]

beetje offtopic misschien...
maar als het parsen van iets langer duurt, kost het dan ook altijd meer rekenkracht voor de computer?

[drm]

pietje63:
beetje offtopic misschien...
maar als het parsen van iets langer duurt, kost het dan ook altijd meer rekenkracht voor de computer?

Als iets elke keer opnieuw geparsed moet worden (zoals met PHP dus het geval is), ja.

[Verwijderd]

ik bedenk me dat het misschien leuk en ontzettend handig is om een soort library aan te leggen met hoe je je script optimaal kan verbeteren. Bijvoorbeeld een (sticky) topic waar iedereen z'n vondsten kan plaatsen? Als er bijvoorbeeld iemand is die de echo en print verschillen gaat onderzoeken kan ie het daar kwijt.
Dit kan uitgroeien tot een erg handige resource voor scripters die met een grote site bezig zijn...

wat vinden jullie?

[Rense Klinkenberg]

Zoals eerder is gezegd is het afhankelijk van de configuratie van het syteem hoe snel bepaalde stukken code worden uitgevoerd. Iemand die wel de zend optimizer gebruikt, zal niet hoeven te letten op het verschil tussen $a = 'dit is een zin" en $a = 'dit is een zin'.

Verder levert een google zoektocht ook al wel redelijk wat op, omdat er op internet al veel benchmarks staan.

Een ander punt om er geen sticky topic voor te maken is het feit dat mensen daar simpelweg toch niet in kijken. Let maar eens op hoe vaak de laatste tijd er wel niet is gevraagd waarom scripts het niet doen, waarbij de oorzaak lag aan de register_globals optie in php.ini.

[Verwijderd]

dat maakt echt niks uit hoor als je zon site als cu2.nl bijv. (waar de breezahcommunity als gek bezoekt *kon het nie latuh*) dan merk je het met server nog niet eens dus jah... boeiuh

[Bolk]

We hebben (Hdd en ik) wel eens wat benchmarks gedraait en print was iig wel sneller dan echo. Ik denk dat je gewoon moet nemen wat je het makkelijkste vind

Ik vind bijv echo handiger maar ik gebruik print (beetje krom maargoe )