[PHP] Snelle en efficiënte code schrijven

[Twan V]

Voor veel dingen die je programmeert in PHP zijn er meerdere oplossingen. Om een voorbeeld te geven, als je iets wilt echo-en kun je print() gebruiken of echo(), maar ook kun je je php-blok afsluiten en daarna weer openen ( ?> Blablabla <?php ).

ik ben op het idee van dit topic gekomen door deze site, waaruit blijkt dat echo sneller is dan print.

Nu ben ik benieuwd welke (snelle) methodes jullie voor diverse problemen gebruiken, en welke functies jullie verkiezen boven anderen. Om het wat duidelijker te maken, ga je voor mysql_fetch_array, _assoc of _object? Kies je een switch/case of een if/else?

Voordat er verkeerde discussies losbarsten, we gaan het niet hebben over correcte/nette/fijne code, want daarover verschillen de meningen nogal. Iedereen vindt zijn/haar syntaxschrijfwijze heilig, maar daar gaat het niet om. Het gaat mij om parse-snelheid.

Misschien wordt dit zo wel een leuk naslag-topic

[ Voor 1% gewijzigd door Twan V op 21-09-2004 22:28 . Reden: 3x gepreviewd en nog zitten er spelvouten in :S ]

[djluc]

Ondanks dat ik het niet echt een belangrijke discussie vind omdat dit soort kleine zaken niet echt het belangrijkste zijn, het is meer een opsomming van snelle functies, toch even een antwoord op je vraagje:

ga je voor mysql_fetch_array, _assoc of _object? Kies je een switch/case of een if/else?

assoc is sneller. Verder is de keuze if/else of switch/case afhankelijk van het gebruik: switch gebruik je alleen als je 1 variable wilt vergelijken met een x aantal andere. Met if kan je veel meer.

[Mithrandir]

Ehm

Ik heb ooit wel eens metingen gedaan met echo, print en al dan niet inline variabelen ("bla ".$bla." woei" vs "bla $bla woei") en dat maakte totaal NIETS uit. Op 10.000 maal herhalen was er een marginaal verschil, maar bij een F5 kon 't net andersom zijn.

Verder is de vuistregel dat objecten langzamer zijn dan arrays, en dat je vaak arrays ook wel mee kunt geven per reference, wat vooral bij grotere arrays nog wel eens een beetje tijd scheelt.

Maar over het algmeen geldt dat je op gewone statements amper tijd verliest. Je kunt veel beter gaan nadenken over hoe je het aantal queries kunt verminderen, of welke code vaak wordt uitgevoerd. Daar moet je verbeteren. En die laatste milliseconde kost je meer om te programmeren dan dat het je werkelijk kost als je ooit een serverupgrade moet doen.

(Of zend optimiser kopen in plaats van uren besteden aan het behalen van milliseconden)

[Verwijderd]

Twan V schreef op 21 september 2004 @ 22:27:
Het gaat mij om parse-snelheid.

Bedoel je niet execute snelheid?

[Grijze Vos]

Ik gebruik foreach nogal vaak, dan moet je wel assoc gebruiken, anders loop je twee keer door dezelfde zooi heen.

[plakbandrol]

Het starten en afsluiten van php blokken doe ik ook regelmatig, ben toch wel benieuwd of dit echt trager/sneller is dan alles binnen 1 blok te doen

wat ik vaak doe is bij formulieren kleine stukjes php te gebruiken

je hebt dus een aantal textvakjes op deze manier

code:

<input type="text" name="naam" value="<?=$naam?>">

zou dit nou merkbaarder trager zijn als:

PHP:

echo "<input type=\"text\" name=\"naam\" value=\"$naam\">";

[ Voor 31% gewijzigd door plakbandrol op 22-09-2004 02:07 ]

[Grijze Vos]

plakbandrol schreef op 22 september 2004 @ 02:05:
Het starten en afsluiten van php blokken doe ik ook regelmatig, ben toch wel benieuwd of dit echt trager/sneller is dan alles binnen 1 blok te doen

wat ik vaak doe is bij formulieren kleine stukjes php te gebruiken

je hebt dus een aantal textvakjes op deze manier

code:

<input type="text" name="naam" value="<?=$naam?>">

zou dit nou merkbaarder trager zijn als:

PHP:

echo "<input type=\"text\" name=\"naam\" value=\"$naam\">";

loopje van 10K tries:

#1 -> 7.1646571159363

#2 -> 14.808480024338

Je eerste is +- 2x zo snel.

[Twan V]

djluc schreef op 21 september 2004 @ 22:46:
Ondanks dat ik het niet echt een belangrijke discussie vind omdat dit soort kleine zaken niet echt het belangrijkste zijn...

Ik heb een tijdje geleden een systeempje gemaakt met 50 comboboxen op een pagina, met een 400 opties per stuk (de klant wilde het écht zo, de output was iets minder dan 1MB ). Dan is elke honderdste seconde die je kunt missen meegenomen.

Thuis werk ik met een erg trage server die eigenlijk teveel tegelijk doet. Ik heb phpAccel (ooit ergens gevonden) er al opgezet, maar dat helpt geen reet.

Verwijderd schreef op 22 september 2004 @ 00:04:
[...]
Bedoel je niet execute snelheid?

Euhm ja, voor mijn doen was het al laat gisteren

[Kuhlie]

Twan V schreef op 22 september 2004 @ 08:56:
[...]


Ik heb een tijdje geleden een systeempje gemaakt met 50 comboboxen op een pagina, met een 400 opties per stuk (de klant wilde het écht zo, de output was iets minder dan 1MB ). Dan is elke honderdste seconde die je kunt missen meegenomen.

(...)

offtopic:
Ik gok dat dat 50 comboboxen met dezelfde 400 opties waren. Waarom vul je die dan niet met javascript?

[drm]

Ik vind dit soort dingen altijd wel grappig. Je hebt het hier echt over microseconden; alsof je daar als gebruiker ook maar ene fluit van merkt. Je kunt veel beter goed nadenken over het opzetten van een snel en efficiente database, de queries en het verwerken van die data, dan nota bene het allerlaatste futiligheidje waar je mee bezig bent: je data printen.

[Banpei]

Kuhlie schreef op 22 september 2004 @ 09:40:

offtopic:
Ik gok dat dat 50 comboboxen met dezelfde 400 opties waren. Waarom vul je die dan niet met javascript?

Heb jij wel eens JavaScript los gelaten op 50 comboboxen met 400 opties?

Dat is nog fijn als je een degelijke pc hebt, maar niet van een wat ouder type als een P2 bijvoorbeeld.

[JasperE]

drm schreef op 22 september 2004 @ 09:44:
Ik vind dit soort dingen altijd wel grappig. Je hebt het hier echt over microseconden; alsof je daar als gebruiker ook maar ene fluit van merkt. Je kunt veel beter goed nadenken over het opzetten van een snel en efficiente database, de queries en het verwerken van die data, dan nota bene het allerlaatste futiligheidje waar je mee bezig bent: je data printen.

Helemaal mee eens, het enige wat ik belangrijk vind is dat je of echo, of print consequent gebruikt en niet steeds door elkaar in hetzelfde script. Voor die paar microseconden maakt het absoluut niet uit.

[crisp]

Banpei schreef op 22 september 2004 @ 09:46:
[...]

Heb jij wel eens JavaScript los gelaten op 50 comboboxen met 400 opties?

Dat is nog fijn als je een degelijke pc hebt, maar niet van een wat ouder type als een P2 bijvoorbeeld.

Dat ligt volledig aan je JS-skillz

[Twan V]

OD-Frozen schreef op 22 september 2004 @ 09:47:
[...]

Helemaal mee eens, het enige wat ik belangrijk vind is dat je of echo, of print consequent gebruikt en niet steeds door elkaar in hetzelfde script. Voor die paar microseconden maakt het absoluut niet uit.

Daar heb je wel gelijk in, maar het ging me ook niet alleen om het printen van data.

Anders gevraagd: Wat is nu de efficiëntste manier om met MySQL om te gaan?

[Sjaaky]

Wat bij php erg belangrijk is is dat je zoveel mogelijk gebruik moet maken van de ingebouwde functies. Als je bijvoorbeeld een karakter in een string zoekt met je eigen while loopje is dat vele malen langzamer dan de php functie die daarvoor bestemd is.
Voor mij was dat even wennen (waarschijnlijk meer mensen die gecompileerde talen gewend zijn). In een gecompileerde taal maakt het namelijk niet zoveel uit of je de ingebouwde functie gebruikt of je de functie zelf schrijft.

Over dingen als echo vs print, ' vs " maak ik me niet druk, ik doe alles overal op dezelfde manier. Dat is dubbele quotes voor php strings en enkele quotes voor de html die erin staat. Het escapen van quotes in een string doe ik liever niet.

[crisp]

Sjaaky schreef op 22 september 2004 @ 10:03:
[...]
Over dingen als echo vs print, ' vs " maak ik me niet druk, ik doe alles overal op dezelfde manier. Dat is dubbele quotes voor php strings en enkele quotes voor de html die erin staat. Het escapen van quotes in een string doe ik liever niet.

Andersom is logischer imho; al je strings in PHP tussen dubbele quotes is trager (marginaal maar toch), en je bent verplicht altijd ENT_QUOTES te gebruiken bij htmlentities en htmlspecialchars als je attributen wilt vullen in HTML...

[Creepy]

Sjaaky schreef op 22 september 2004 @ 10:03:
Wat bij php erg belangrijk is is dat je zoveel mogelijk gebruik moet maken van de ingebouwde functies. Als je bijvoorbeeld een karakter in een string zoekt met je eigen while loopje is dat vele malen langzamer dan de php functie die daarvoor bestemd is.
Voor mij was dat even wennen (waarschijnlijk meer mensen die gecompileerde talen gewend zijn). In een gecompileerde taal maakt het namelijk niet zoveel uit of je de ingebouwde functie gebruikt of je de functie zelf schrijft.

Geen idee welke gecompileerde taal jij gebruikt, maar als ik standaard functies tot m'n beschikking heb ga ik echt zelf geen implementatie hiervoor schrijven. Het nut ervan is meestal 0 en ook in dit geval is het meestal trager (!). Je zou voor de gein je eigen functies eens moeten benchmarken met de standaard functies.

[djluc]

Verder is het zelf namaken van functies natuurlijk gewoon tijdsverspilling. Je krijgt meer code dan noodzakelijk is. Zelf functioniteit namaken is imo alleen handig als de functionaliteit van de originele functie niet toereikend is. En zelfs dan zou je eens kunnen kijken of je met de taal niet de functionaliteit kan uitbreiden.

[Verwijderd]

Grijze Vos schreef op 22 september 2004 @ 00:26:
Ik gebruik foreach nogal vaak, dan moet je wel assoc gebruiken, anders loop je twee keer door dezelfde zooi heen.

Maar wat is dan sneller?

code:

mysql_fetch_array($query_result, MYSQL_ASSOC)

of

code:

mysql_fetch_assoc($query_result)

[Verwijderd]

Verwijderd schreef op 22 september 2004 @ 11:03:
Maar wat is dan sneller?

code:

mysql_fetch_array($query_result, MYSQL_ASSOC)

of

code:

mysql_fetch_assoc($query_result)

Dat zal vast niet veel uitmaken. Maar ja, meten is weten.

Ik heb ooit (in een grijs verleden) eens meegedaan aan een programmeerwedstrijdje van PC Magazine. De opdracht was om een bepaald algoritme (in Turbo Pascal!) te optimaliseren. Wie dat het beste deed had gewonnen.

Je kon aardig wat winnen door bepaalde instructies te kiezen boven andere. Misschien wel een factor 2 of zo. Maar dat was niets vergeleken met wat je kon behalen als je het algoritme fundamenteel wijzigde (het moest wel dezelfde uitkomst geven natuurlijk). Dat scheelde een factor 50 of zo.

[whoami]

Twan V schreef op 22 september 2004 @ 09:59:
[...]


Anders gevraagd: Wat is nu de efficiëntste manier om met MySQL om te gaan?

Indexen leggen daar waar ze nodig zijn; geen indexen leggen waar ze niet nodig zijn.

[WormLord]

Grijze Vos schreef op 22 september 2004 @ 02:23:
[...]


loopje van 10K tries:

#1 -> 7.1646571159363

#2 -> 14.808480024338

Je eerste is +- 2x zo snel.

En als je de echo-variant veranderd in

PHP:

echo "<input type=\"text\" name=\"naam\" value=\"".$i."\">";

dan ben je dat snelheidsverschil weer kwijt.

[Verwijderd]

Ja en nog sneller is de double quotes vervangen door single quotes.. Kom op mensen, liever duidelijke nette bruikbare code dan dat gemieren neuk om een paar micro nano secondes voor die paar echo's die je in je script hebt...

Als we zo beginnen kijk dan ook eens naar je string gebruik? (onnodig veel concatenere) Of te veel type juggling.. .etc..

[Gomez12]

En kijk ook eens naar je variabelen namen. Elke byte is er een extra die php moet interpreteren (/van schijf halen), dus is $1 sneller als $topicstarter.

Maar ff serieus, als je het php echt perse sneller wilt hebben. Kijk dan eerst eens naar de zend-optimizer voordat je dit soort rare fratsen uit gaat zitten halen. Zoals al een paar keer gezegd is leesbare code veel beter dan ms snellere code. Gewoon nette / correcte code schrijven en dit soort dingen heeft niet veel effect voor de eindgebruiker ( in 99% van de php-scripts ).

[blizt]

Gomez12 schreef op 22 september 2004 @ 19:43:
En kijk ook eens naar je variabelen namen. Elke byte is er een extra die php moet interpreteren (/van schijf halen), dus is $1 sneller als $topicstarter.

offtopic:
Ik neem aan dat je dit niet serieus bedoelde, maar verder kan het niet eens
Een variable in PHP mag niet beginnen met 'n cijfer, dus ontstaat er 'n parse error als hieronder:
Parse error: syntax error, unexpected T_LNUMBER, expecting T_VARIABLE or '$'

[MisterData]

Ook een goede:

PHP:

for($a=0;$<mysql_num_rows($results);$a++) {
   ....
}

// Is trager dan:

for($a=0,$n=mysql_num_rows($results);$a<$n;$a++) {
   ...
}

[kvdveer]

Als je responstijd gaat meten (zonder optimizer of cache) dan blijkt dat een flink deel van je tijd gaat zitten in parsetime - bij eenvoudige (queryloze) code is dat al snel een kwart, zodra je functies, loops en/of queries gaat gebruiken dan stelt die parsetime bijna niets meer voor.

String-handling is relatief traag in php, je kunt dat beter zo lang mogelijk uitstellen.

PHP:

$var = "tralala $variabele tralalalala";

is ca 10%-20% trager dan

PHP:

$var = "tralala " . $variabele ." tralalalala";

als je 't moet echoën dan is

PHP:

echo "tralalala " , $variabele , " tralala"

nog weer ca. 50% sneller.

Arrays met integer-indexen zijn sneller dan arrays met gemengde (string en evt. int) indexen.

/Tot zo ver wat er hier in mijn kennis-databaseje zit.

blizt schreef op 22 september 2004 @ 19:51:
[...]

offtopic:
Ik neem aan dat je dit niet serieus bedoelde, maar verder kan het niet eens
Een variable in PHP mag niet beginnen met 'n cijfer, dus ontstaat er 'n parse error als hieronder:
Parse error: syntax error, unexpected T_LNUMBER, expecting T_VARIABLE or '$'

Er zijn helemaal geen restricties voor variabelenamen in PHP. Alle namen zijn toegestaan, al moet je sommige quoten.
Voor een php-obfuscation contest:

PHP:

$een = 1;
${1} = "een"

echo $$een;
echo $${1};

[eborn]

Verwijderd schreef op 22 september 2004 @ 19:26:
Ja en nog sneller is de double quotes vervangen door single quotes.. Kom op mensen, liever duidelijke nette bruikbare code dan dat gemieren neuk om een paar micro nano secondes voor die paar echo's die je in je script hebt...

Single-quotes in HTML output? Lijkt me niet heel wenselijk, vooral niet als je XHTML compliant wilt zijn

Ik gebruik daarom altijd lekker:

PHP:

print '<td style="width: 100px">'.$text.'</td>'."\n";

[ Voor 12% gewijzigd door eborn op 22-09-2004 20:32 ]

[coubertin119]

offtopic:
Single quotes valideren ook perfect hoor .

---

Verwijderd schreef op 22 september 2004 @ 20:46:
[...]


Gelukkig stond er dan ook HTML en niet XHTML.

Er staat weldegelijk XHTML .

[ Voor 76% gewijzigd door coubertin119 op 22-09-2004 20:47 ]

[Verwijderd]

eborn schreef op 22 september 2004 @ 20:32:
Single-quotes in HTML output? Lijkt me niet heel wenselijk, vooral niet als je XHTML compliant wilt zijn

Gelukkig stond er dan ook HTML en niet XHTML.

[eborn]

coubertin119 schreef op 22 september 2004 @ 20:46:

offtopic:
Single quotes valideren ook perfect hoor .

Grappig, wist ik niet

[Cloud]

Twan V schreef op 21 september 2004 @ 22:27:
Nu ben ik benieuwd welke (snelle) methodes jullie voor diverse problemen gebruiken, en welke functies jullie verkiezen boven anderen. Kies je een switch/case of een if/else?

Dat hangt af van de situatie, maar switch/case is gewoon een handigere manier (in sommige gevallen) dan if-statements, ze werken voor zover ik weet intern, echter compleet hetzelfde. Alleen andere formulering dus

[crisp]

Wat bij if's en switch/case constructies wel uitmaakt is de volgorde waarin je de afvragingen doet; bij OR-afvragingen beginnen met de most-likely casus en bij AND-afvragingen met de least-likely

[Sendy]

Na het interpreteren kan de code van een switch statement heel anders functioneren. Dat ligt dan voornamelijk aan de hoeveelheid cases. Je kan bijvoorbeeld een tabel aanmaken met pointers naar de code, of een lijst van simpele branches met hardgecodeerde offsets. En je weet niet hoe PHP de handel optimaliseerd, dus kan je niets zeggen over de (interne) werking van de switch statement.

[ Voor 6% gewijzigd door Sendy op 22-09-2004 21:42 ]

[TheBorg]

drm schreef op 22 september 2004 @ 09:44:
Ik vind dit soort dingen altijd wel grappig. Je hebt het hier echt over microseconden; alsof je daar als gebruiker ook maar ene fluit van merkt.

Er bestaat ook nog zoiets als websites met meer dan 300.000 bezoekers per dag en iets dat server load wordt genoemd.

[blizt]

Er zijn helemaal geen restricties voor variabelenamen in PHP. Alle namen zijn toegestaan, al moet je sommige quoten.
Voor een php-obfuscation contest:

PHP:

$een = 1;
${1} = "een"

echo $$een;
echo $${1};

Maar wat je nu doet, is als eerste teken 'n { gebruiken een cijfer ... imho
Maar dit raakt off-topic.

[TheRebell]

wat ik me ook wel afvraag of het op een of andere manier sneller is als je al je SQL statements in een array zou opslaan, en telken svanuit je code hiernaar zou verwijzen ipv de statements direct in je code zetten. Het is echt langzamer volgens mij maar uit het oogpunt van onderhoud wel veel makkelijker.

Ik denk dat je gewoon een balans moet hebben tussen goed/leesbaar/netjes coden en het op een efficiente manier (lees: lage load) doen. Verder zal het wel redelijk meevallen

[Sjaaky]

djluc schreef op 22 september 2004 @ 10:40:

Verder is het zelf namaken van functies natuurlijk gewoon tijdsverspilling. Je krijgt meer code dan noodzakelijk is. Zelf functioniteit namaken is imo alleen handig als de functionaliteit van de originele functie niet toereikend is. En zelfs dan zou je eens kunnen kijken of je met de taal niet de functionaliteit kan uitbreiden.

Wat ik meer bedoelde (kwam er niet echt uit ) is dat je soms dingen beter iets omslachtiger met ingebouwde functies kan doen, dan een eigen methode gebruiken die wel straight to the point is.

Bijv:
Ik heb ooit een keer een stackbased UBB parser gemaakt. Daarvoor heb je een tokeniser nodig. Ik heb een aantal manieren getest om de invoer te tokenisen. Alle tokenisers retourneren dezelfde datastructuur als tussenrepresentatie (alle manieren zijn dus ook functioneel gelijk).

1. while loop per karakter.
   Detecteren of het een '[', ']', ' ' of '=' is (afhankelijk van de state waarin je bent), anders toevoegen aan de actuele token.
2. strpos tot alle volgende tekens, daar het minimum van nemen. Dan met een strsub het resultaat aan de token toekennen.
3. gebruik maken van strcspn (die loopt door string a tot hij een teken tegenkomt dat ook in string b zit en retourneert het aantal doorgelopen tekens). Dat gebruik je dan om met strsub je token te bepalen.
4. een slimme preg_match_all die alle tokens in een array teruggeeft, die array loop ik vervolgens een keer langs om de tussenrepresentatie te genereren.

De methoden staan hier van langzaam naar snel. Tussen de nummers 4 en 3 zit nauwelijks verschil (vroeger wel, maar sinds php 4.3 accepteert strcspn extra parameters die het geheel sneller maken ). Tussen de nummers 4 en 2 zit zo'n 75% verschil in snelheid. Nummer 1 zou ik niet meer weten, die was iig nog stukken langzamer.
Het punt is dat als ik een tokenizer zou moeten schrijven in C, ik methode 1 zou kiezen. Ik heb dat niet gebenchmarkt, maar verwacht dat dat de snelste methode is. Bovendien is het algoritme erg helder. Ik zou zeker niet aan de slag gaan met regular expressions in C om een string te tokenisen, terwijl die in dit geval de gedeelde eerste plaats qua snelheid opeist.

[PrisonerOfPain]

Wolkjeh schreef op 22 september 2004 @ 21:16:ze werken voor zover ik weet intern, echter compleet hetzelfde. Alleen andere formulering dus

Toch niet, zie de zend_do_if* en zend_do_case* funties in /Zend/compile.c