[php] inefficient programmeren maakt dat nog wat uit?

[vorlox]

Beste ,

Na het lezen van het topic "PHP Vraagstuk"
Rees er bij mij eigenlijk een vraag.

Hoeveel maakt het uit als je soms "ranzig" (niet mijn woorden) programmeert

Dus in het vorige topic ontstond een kleine discussie over ongeveer twee voorbeelden

PHP:

<?
//Vull array...snel
$var = array('test','test','test','test','test','test');

//manier netjes
foreach($var as $value)
{
   print $var;
} //End foreach($var as $value)


//Ranizge manier!
$counter = count($var);
$i=0;
while($i<=$counter)
{
   print $var[$i];
   $i++;
}

?>

Wat mijn vraag nu is lijkt me duidelijk...is er enige merkbaar performance verlies tussen deze twee vormen.

en wat nu als je toch een pointer nodig hebt tussen de foreach of while.
dan ga ik er vanuit dat je $i ook mee moet laten lopen met een foreach

[JoostBaksteen]

Het maakt zeker veel uit, draai maar eens een benchmark die alles 1000 keer doet, dan merk je het verschil ernorm.

[gorgi_19]

Ik geloof dat ik een keer heb gelezen dat 10% van je code 90% van de verwerktijd inneemt.
Je zult je aandacht moeten richten om deze 10% te optimaliseren. En die 0.0000001 seconde verwerktijd zal weinig uitmaken.

Bovenstaande voorbeelden kan je imho ook zelf testen..

[vorlox]

zoo ok
Tja je word iedere keer beter...Als ik naar mijn oude scripts kijk wordt ik daar niet direct vrolijk van...

met wat voor tool draai je php benchmarks..op een linux-redhat doos met plesk(php-apache-administrator pakket)...ik heb ook gewoon root access hoor dus ik kan compilen wat ik wil evt.

[Tha_Butcha]

idd. ranzig programmeren is niet zo erg als je gewoon in je eentje wat maakt, en in je eentje gebruikt.

Performance is idd. een belangrijke reden, maar ook gewoon netjes coden is makkelijker als je samen moet werken, of zelfs als je je eigen code over een half jaartje ziet, kom je er niet uit.

Ow ja, nog iets, als je niet netjes code, is de kans groter dat er beveiligings gaten inslijpen (lijkt me).

[sebas]

Wat is netjes coden dan?

Ik denk dat het in bovenstaand voorbeeld niet veel uitmaakt, als het een af en toe gebruikt scriptje is, als het 3 keer peer jaar wordt aangeroepen ... lekker boeien.

Als een script wat 100000 pageviews per dag moet verwerken ranzig gecode is merk je dat sneller.

Plus dat ranzigheid natuurlijk totaal geen eenduidig begrip is.

Je kan heel nette code hebben die enorm inefficient is omdat de structuur misschien wel voldoet aan allerlei l33t3 designpatterns maar het in de situatie totale overkill is. Aan de andere kant kun je soms door het script uit te breiden en dingen handmatig te doen die soms door functies worden gedaan performance winnen, waar het nodig is. Op welke criteria baseer je ranzigheid? Is bijvoorbeeld alles wat niet OO gecode is ranzig? Is een script sowieso ranzig als je nooit foreach() gebruikt en altijd een loop gebruikt?

Redelijk onduidelijk begin voor een topic vind ik.

[Janoz]

Waneer je al je elementen in een array af wilt gaan kun je het beste de constructie gebruiken die daarvoor bedoeld is.

Je 'ranzige' voorbeeld kan fout gaan. In php staat helemaal niet vast dat het indexnummer ook zonder gaten oploopt. Waneer je de boundaries van de lus door het aantal elementen laat bepalen kun je dus elementen missen (en een soort nullpointer exceptions krijgen, maar daar kun je bij php natuurlijk al helemaal niet over spreken)

Micro efficientie is IMHO iets waar je met de tegenwoordige rekenkracht niet zo heel veel rekening meer mee moet houden. Het is veel belangrijker om duidelijke code te schrijven zodat deze veel onderhoudbaarder is. In de praktijk komt het er tegenwoordig toch vaak op neer dat het goedkoper is om computerkracht bij te kopen voor een duidelijk en onderhoudbaar maar inefficient programma dan de arbeidskosten van het onderhouden van een efficient maar onoverzichtelijk programma.

Om nu nog ff op je start code terug te komen. Stel d'r staat nog een hele boel code omheen en iemand (of jij) voegt wat code toe waarbij wel een index opgegeven wordt. Op dat moment is de verwachte functionaliteit niet meer gegarandeerd de geleverde functionaliteit. Bij de foreach lus kun je er echter altijd vanuit gaan dat alle elementen bijlangs gegaan worden. Deze zal dus altijd de gewenste functionaliteit leveren.

[Verwijderd]

Re: gorgi_19
Volgens mij was het 20% en 80%, maar het zullen wel andere bronnen zijn geweest.

[ACM]

Het is idd 20 - 80, maar een variant erop is 10 - 90. Wat vaak ook nog waar is.

[Verwijderd]

Pareto principe 80/20 geeft aan dat een gering aantal oorzaken verantwoordelijk is voor het merendeel van de resultaten

[Verwijderd]

Even iets over die foreach() , die werd namelijk pas in versie 4 van PHP.
Dus vroeger moest je wel een gewone for() lus gebruiken of een while() lus.
Waarom is het dan ranzig? Lang niet alle systemen hebbenal PHP4 hoor!

[Varienaja]

Ik weet niet of je bekend bent met complexiteit van berekeningen? Het komt erop neer dat je in een formule berekent hoelang een bepaalde procedure duurt, afhankelijk van de grootte van de invoer ervan.

Als je zo inefficiënt programmeert dat een procedure opeens een 'orde' trager is (n ipv log n, of n² ipv n dan ben je stom bezig. Dat soort inefficiëntie wordt niet opgelost door een snellere processor.

[Access]

Ok, ik heb de proef op de som genomen en beide loopjes (de ranzige en de nette) in een for($t=0; $t<=1000; $t++) loop gezet. De ranzige versie doet er ~0.1090 seconde over. En de nette versie doet er ~0.0704 seconde over. Dat is dus een verschil van ~0.03 seconde.

_{Getest op een P2-233 met php 4.3.1}

[Bosmonster]

vorlox schreef op 09 mei 2003 @ 20:05:
Beste ,

Na het lezen van het topic "PHP Vraagstuk"
Rees er bij mij eigenlijk een vraag.

Hoeveel maakt het uit als je soms "ranzig" (niet mijn woorden) programmeert

Dus in het vorige topic ontstond een kleine discussie over ongeveer twee voorbeelden

De juiste voorbeelden zouden zijn:

code:

foreach (arr as ele) { ... }

while (list(, $line) = each ($arr)) { ... }

Je kunt hier ook wel zien wat leesbaarder is

Maar goed.. wat jij noemt doet ook een hoop onzinnigs, zoals het tellen van de array en voor iedere loop een lookup van het element.. Beiden onnodig

[ Voor 21% gewijzigd door Bosmonster op 10-05-2003 19:22 ]

[sig69]

Access schreef op 10 mei 2003 @ 19:01:
Ok, ik heb de proef op de som genomen en beide loopjes (de ranzige en de nette) in een for($t=0; $t<=1000; $t++) loop gezet. De ranzige versie doet er ~0.1090 seconde over. En de nette versie doet er ~0.0704 seconde over. Dat is dus een verschil van ~0.03 seconde.
_{Getest op een P2-233 met php 4.3.1}

Oftewel 54,8 % sneller

[sjroorda]

Zie voor dit soort getalletjes ook dit topic; hierin heb ik op pag. 2 (bovenste post) een aantal links naar benchmarks gezet die ik zelf heb gedraaid. Helemaal kloppen doen ze niet, maar je moet maar even het hele topic doorlezen.

Ik denk dat met wat logisch nadenken je zelf een heleboel kan voorkomen. Houd er in ieder geval rekening mee dat het grootste verlies hem zit in file-operations (ook DB).

[dusty]

Het ligt er toch zeer zeker aan waarvoor het geprogrammeerd wordt, en op wat voor systeem het draait e.d.

Ik zou graag willen zien dat een bank een net programma draait zonder ranzige code zodat er ook wiskundig aangetoont zou kunnen worden dat het programma correct is. Immers brengt dat de betrouwbaarheid omhoog, hetzelfde voor een hart-monitor.. Ik zou toch niet willen dat de informatie langzamer is dan noodzakelijk omdat een of andere programmeur ranzig heeft geprogrammeerd

Daar tegenover staat wat maakt het mij uit dat een website 0.1 seconden langer laad? maarja.. als webmaster maakt je dat wel weer uit immers als je 10.000 users hebt die allemaal 0.1 seconden langer over hun requests doen is dat best pijnlijk