magic __get __set

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: « vorige 1 2 3 4 volgende »

Kees Schepers

kees Schepers

02/02/2013 10:11:13
Quote Anchor link
Ook een reden dat het steeds minder gebruikt wordt (de magic getters en setters) is omdat je code er minder leesbaar van wordt en ook het debuggen lastiger wordt. Ga maar eens door Zend Framework 1 door met xdebug.

Daarnaast zie je het ook in weinig (geen volgens mij?) andere talen terug. Performance verschil is sowieso verwaarloosbaar.

Ik kan me overigens ook niet echt voorstellen dat magic functions zo bijster veel geheugen gebruiken, maar dat zou je ook kunnen benchmarken :)
Gewijzigd op 02/02/2013 10:14:03 door kees Schepers
 
PHP hulp

PHP hulp

27/04/2024 06:23:19
 
Bart V B

Bart V B

02/02/2013 10:30:10
Quote Anchor link
Mannen,

Ik weet goed dat dit topic puur over getters en setters gaat.
Toch loopt in dit topic een klein rood lijntje over performance.
Dus tijdens het lezen ben ik daar eens over na gaan denken, en had een tijdje geleden eens een interview gezien met Rasmus Lendorf. Neem aan dat jullie weten wie dat is, maar mocht dat nog niet duidelijk zijn dat is die rakker die de eerste steen heeft gelegd wat betreft php.

In dat interview werd gevraagd wat zijn mening was over phpHipHop.
Dat is het php platform waar het welbekende bakkusboek op draait.
Het voordeel van dit php platform is dat het een stuk sneller zou zijn.
Aan de andere kant was zijn mening voor every day programming het een stuk lastiger was om php hiphop te installeren.

Dus als je/we toch iets aan het maken zijn wat echt performance nodig heeft (hoewel ik betwijfel of dat met een klein servertje voordeel heeft) zou het misschien wel een optie zijn als het allemaal wat serieuzer word.

Ik zal van de week eens een poging wagen om een installatie van phpHipHop te doen.
Mocht ik daarin slagen, dan zal ik mijn bevindingen daarover met jullie delen.
 
Koen Vlaswinkel

Koen Vlaswinkel

02/02/2013 11:25:21
Quote Anchor link
Ik heb even gebenchmarkt en de 'normale' getters en setters zijn ongeveer 20% sneller dan magic methods op een Linux server:
Afbeelding

Met dank aan Wouter J's PHPBench.
Gewijzigd op 02/02/2013 11:59:48 door Koen Vlaswinkel
 
Erwin H

Erwin H

02/02/2013 11:54:18
Quote Anchor link
Koen Vlaswinkel op 02/02/2013 11:25:21:
Ik heb even gebenchmarkt en de 'normale' getters en setters zijn ongeveer 120% sneller dan magic methods op een Linux server:

Uhm, dat is wel een heel creatieve methode van het gebruik van procenten. Normale getters en setters zijn dus ongeveer 16% sneller zou een betere conclusie zijn.
 
Wouter J

Wouter J

02/02/2013 12:29:21
Quote Anchor link
Uhmm, ((20 - 19) / 19) * 100% = ±5% sneller
 
Koen Vlaswinkel

Koen Vlaswinkel

02/02/2013 12:33:18
Quote Anchor link
Wouter J op 02/02/2013 12:29:21:
Uhmm, ((20 - 19) / 19) * 100% = ±5% sneller

Ik weet niet waar jij 19 vandaan haalt:
((20 - 16) / 16) * 100% = ±25% sneller

Maar de test varieert tussen de 102-155% met de magic, dus de normale getters en setters zijn sowieso sneller.
 
- Raoul -

- Raoul -

02/02/2013 12:45:18
Quote Anchor link
Je kunt moeilijk alles in vraag stellen. Magic getters en setters zijn misschien dan wel iets trager, maar het verschil merk je gewoon niet.
Gewijzigd op 02/02/2013 12:51:27 door - Raoul -
 
Wouter J

Wouter J

02/02/2013 13:25:18
Quote Anchor link
Koen, ja sorry je hebt gelijk.
 
Ozzie PHP

Ozzie PHP

02/02/2013 15:28:04
Quote Anchor link
Koen Vlaswinkel op 02/02/2013 11:25:21:
Ik heb even gebenchmarkt en de 'normale' getters en setters zijn ongeveer 20% sneller dan magic methods op een Linux server:
Afbeelding

Met dank aan Wouter J's PHPBench.

Hoe heb je dit getest? Welke code heb je gebruikt en hoe vaak heb je die uitgevoerd?
 
Koen Vlaswinkel

Koen Vlaswinkel

02/02/2013 15:36:30
Quote Anchor link
Ik heb Wouter J's PHPBench gebruikt (https://github.com/WouterJ/PHPbench) en daarvoor heb ik deze code gebruikt. Ik heb de code een stuk of 20 keer uitgevoerd, maar dat legt PHPBench niet automatisch vast, dus heb ik ongeveer het gemiddelde genomen in dit screenshot. Ik heb resultaten van 102% tot 155% tegenover 100% gehad.
Gewijzigd op 02/02/2013 15:36:53 door Koen Vlaswinkel
 
Ozzie PHP

Ozzie PHP

02/02/2013 15:40:19
Quote Anchor link
Maar... heb je het niet in een loop gegooid zodat het bijvoorbeeld 1000 keer wordt uitgevoerd? Heb je het telkens maar 1x uitgevoerd?
 
Koen Vlaswinkel

Koen Vlaswinkel

02/02/2013 15:41:24
Quote Anchor link
Ja, dat wel, ik kan het nog eens testen met een loop.
 
Ozzie PHP

Ozzie PHP

02/02/2013 15:43:40
Quote Anchor link
Ja, zoiets moet je juist testen met een loop! Bijvoorbeeld 100.000 keer de code uitvoeren. Pas dan krijg je een beetje zinnige resultaten namelijk.
 
Koen Vlaswinkel

Koen Vlaswinkel

02/02/2013 15:47:19
Quote Anchor link
Ik heb nu de volgende resultaten met een loop van 1000 telkens:
Magic vs Getters and setters
100% vs 104%
107% vs 100%
185% vs 100%
108% vs 100%
136% vs 100%
116% vs 100%
118% vs 100%
119% vs 100%
167% vs 100%
133% vs 100%
 
Ozzie PHP

Ozzie PHP

02/02/2013 15:49:34
Quote Anchor link
Vreemd... er zitten een paar hele grote verschillen tussen... je omgeving lijkt niet heel stabiel :)
 
Koen Vlaswinkel

Koen Vlaswinkel

02/02/2013 15:52:44
Quote Anchor link
Maar het is wel duidelijk dat normale getters en setters meestal sneller zijn dan de magic method __get en __set.
 
Ozzie PHP

Ozzie PHP

02/02/2013 15:54:58
Quote Anchor link
Yep... dat is zeker waar...
 
- Raoul -

- Raoul -

02/02/2013 15:57:46
Quote Anchor link
... Maar het verschil is verwaarloosbaar....
 
Erwin H

Erwin H

02/02/2013 15:59:47
Quote Anchor link
Inderdaad, dit is geen verschil in een serieuze orde van grootte, nog geen factor 2.
 
Ozzie PHP

Ozzie PHP

02/02/2013 16:02:19
Quote Anchor link
Wanneer zouden er eigenlijk WEL merkbare verschillen optreden? Vanaf welke factor?
 

Pagina: « vorige 1 2 3 4 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.