benchmark tip
Als je in een class method (functie) meerdere keren een class property nodig hebt, dan kun je deze property beter eerst in een variabele stoppen. Ik had al zo'n vermoeden dat dat sneller zou zijn, maar ik heb het gebenchmarkt en het blijkt ook inderdaad iets sneller te zijn.
In plaats van dit:
Code (php)
...kun je beter dit doen.
En hoeveel scheelt dat nou?
Heb je ook je geheugen gebruik getest? Dat kan juist weer iets vergroten (is vermoeden zonder meteen getest te hebben)
@TJVB: nee, ik heb het geheugenverbruik niet getest, maar je praat over 1 variabele binnen een functie. Zodra de functie niet wordt gebruikt wordt de geheugenruimte vrij gemaakt. Ik kan me dus niet voorstellen dat dat heel spannend is.
Deze optimalisatie zal er ook niet voor zorgen dat je applicatie ineens gruwelijk sneller wordt. Persoonlijk vind ik het soms netter om een property in een variabele te stoppen in plaats van telkens $this->blabla[$key] te moeten doen. En als het dan ook nog snelheidsvoordeel oplevert? Tja, dan is er geen reden om het niet te doen. 2 Vliegen in één klap. Maar je moet het natuurlijk alleen doen als je meer dan 1x de property aanspreekt. Dit is bijvoorbeeld totaal nutteloos:
Code (php)
Dat doe je uiteraard gewoon zo:
Gewijzigd op 14/03/2013 12:40:09 door Ozzie PHP
Wat mij betreft hoort dit dus weer onder het kopje 'nutteloze microoptimalisatie' en 'voorkeur'.
En zoals Wouter al zegt, dit is microoptimalsiatie.
Ja, en wat dan nog als het micro-optimalisatie is? Ik geef het gewoon als tip. En zoals bijna alles is ook dit een kwestie van persoonlijke voorkeur, maar dan wel eentje met voordelen. Ik zeg helemaal niet dat je het moet doen, ik geef het gewoon mee als tip. En... altijd dan weer heel erg leuk als er zo ongelofelijk vriendelijk wordt gereageerd... ahum.
Sorry Ozzie, het was niet onvriendelijk bedoeld. Maar ik bedoelde met mijn opmerkingen over het geheugen dat een optimalisatie op 1 punt nadelig kan zijn op een ander punt.
Oké dat kan ik nog begrijpen, maar als ik de 2 reacties van Wouter lees (met name het woordje "nutteloze"), dan vind ik het jammer dat er niet eens een keertje positief wordt gereageerd. Het is meteen weer "hakken waar we hakken kunnen". Ik geef hier gewoon goedbedoeld een tip.
Quote:
maar als ik de 2 reacties van Wouter lees
jammer dat je hier dan meteen gaat generalizeren door al mijn reactie in dit topic slecht te keuren. Die eerste was gewoon een goed bedoelde vraag, want als het veel uitmaakt ga ik het echt wel aanpassen (zoals ik bijv. ook heb gedaan toen iemand me vertelde dat de pReg lib traag was en captured groups al helemaal)
Overigens is het niet alleen bij class properties sneller om ze in een variabele te zetten, ook bij array-waardes scheelt het een paar CPU-cycles. PHP kent namelijk eigenlijk helemaal geen arrays, maar implementeert ze onder water als een hash table. Wanneer je een array-waarde opvraagt, moet PHP eerst een hash berekenen en vervolgens een linked list aflopen om de waarde te vinden.
Maar ook dan blijft het een micro-optimalisatie. De voornaamste reden om al dan niet gebruik te maken van variabelen zou in mijn ogen de leesbaarheid van de code moeten zijn. Soms is het leesbaarder om variabelen te gebruiken, soms niet.
Als je door een verhoogde leesbaarheid van je code over een paar maanden een minuut minder lang op je code hoeft te studeren om te begrijpen wat het ook weer doet, heb je al meer gewonnen dan je met micro-optimalisaties kunt bereiken.
Anyhow, ik vind het jammer dat je iets gelijk bestempelt als nutteloos. Dat is nergens voor nodig. Iedere optimalisatie hoe klein ook is sowieso nuttig.
Een micro-optimalisatie lijkt in 1e instantie misschien niet zo heel spannend, maar stel je het volgende eens voor. Iemand op een webshop vraagt een productlijst op van 100 producten. Jij hebt een class met daarin een property $products waarin die 100 producten staan. Per product toon jij in de webshop een titel, een thumbnail, een korte omschrijving, 3 eigenschappen, een productcode, de beschikbaarheid en de prijs. Dat zijn al 7 aanroepen. Dat betekent dat jij 700 keer een trage aanroep doet. Ik doe per product slechts 1x een trage aanroep. De 700 aanroepen die ik daarna doe zijn allemaal sneller. En dat zal zeker een verschil maken.
Het is wel een goede tip, maar ik betwijfel of iemand echt hier rekening mee gaat houden tijdens het programmeren om 0.01 microseconde te besparen.
Je hoeft er ook geen rekening mee te houden, maar het is beter voor je leesbaarheid en het levert snelheidswinst op. Maar zoals ik al zei, je moet helemaal niks. Het is slechts een tip.
Ozzie PHP op 14/03/2013 17:34:00:
Dat betekent dat jij 700 keer een trage aanroep doet. Ik doe per product slechts 1x een trage aanroep. De 700 aanroepen die ik daarna doe zijn allemaal sneller. En dat zal zeker een verschil maken.
In de benchmarks die ik ooit (jaar of vijf geleden) heb gedaan was het verschil iets van 0,15 seconden voor 100.000 aanroepen. Voor die 700 trage aanroepen waar je het over hebt, praat je dus over een verschil van maar liefst een hele milliseconde. Ik denk niet dat de gemiddelde gebruiker daar wakker van ligt. Een goed geplaatste index op je productendatabase levert meer snelheidswinst op.
Ach ja, iedereen gewoon lekker doen waar ie zelf zin in heeft. Ik zal voortaan m'n bevingen niet meer posten hier.
Ozzie PHP op 14/03/2013 17:50:25:
Ach ja, iedereen gewoon lekker doen waar ie zelf zin in heeft. Ik zal voortaan m'n bevingen niet meer posten hier.
Jammer, van alleen maar OOP-huiswerk van scholieren en OOP-theorie van studenten wordt een PHP-forum ook niet beter.
Precies! Spijker op z'n kop Ward. Maar blijkbaar wordt het jammer genoeg door sommigen niet zo heel erg gewaardeerd.
Ozzie PHP op 14/03/2013 17:50:25:
Ik zal voortaan m'n bevingen niet meer posten hier.
Die bevindingen -en de discussie die erop volgt- zijn juist interessant. Het enige wat ik jammer vind is dat je alleen maar zegt dát het sneller is, maar er verder niet bij uitlegt wat je precies hebt gedaan en wat de resultaten (snelheidsverschillen) waren, want dat maakt de materie juist een stuk inzichtelijker.
In de meeste gevallen zijn micro-optimalisaties zonde van je tijd, maar het is wel belangrijk om te weten of iets al dan niet een micro-optimalisatie is, juist omdat je dan kunt inschatten of het de moeite waard is om te gaan optimaliseren. Heb je een seconde snelheidsverschil bij 100 operaties, of pas bij 100.000? Op een van mijn servers krijg ik via http-requests grote hoeveelheden data binnen (ik praat dan over pieken van een half miljoen records die in een kwartier tijd binnenkomen van een stuk of 400 clients) en dan kijk ik echt wel naar micro-optimalisaties. De eerste (grote) optimalisatie die ik dan overigens doe is PHP aan de kant schuiven. ;-)
PHP is een zeer complex stuk gereedschap dat is opgebouwd uit verschillende andere stukken gereedschap (arrays, loopjes, objecten, noem ze maar op). Om optimaal van dat gereedschap gebruik te kunnen maken moet je veel van de ins en outs weten, en die kunnen juist in een discussie als deze boven komen drijven.
Om maar eens wat te noemen: in plaats van een while-loop is het efficiënter om een for-loop te gebruiken. En foreach is zelfs nóg een klein beetje efficiënter. Gebruik in de conditie van je for-loop nooit een functie of een array-reference, maar een simpele variabele. En wil je iets doen met arrays, dan kun je beter gebruik maken van de ingebouwde array-functies van PHP en niet zelf gaan lopen knoeien met loopjes of wat dan ook.
Gewijzigd op 16/03/2013 14:15:31 door Wouter J