[PHP] Is deze code nog te optimaliseren?

[Gerwin]

Ik werk nu al een week aan onderstaande code. De code zorgt op een site van mij voor het genereren van .js bestandjes met een code die voor links zorgt op een website. De links worden uit de database gehaald als het cache .js bestandje nog niet op de server aanwezig is. Ik voeg me af of ik zoiets ook makkelijker kan en minder server belastend? Er moeten per dag ALTIJD 100 links verschijnen. Dus mocht er van de ene categorie "1" bijv niets in de database staan moet ie doorgaan naar 2 enz. De laatste mag 2x zoveel voorkomen als de anderen.

PHP:

    setlocale (LC_ALL, 'nl_NL');

    $strGotd=strftime ("%e %B %Y", mktime(0,0,0,date("m"),date("d")-0,date("Y")));

    $todayTitel=strftime ("%A %e %B %Y", mktime(0,0,0,date("m"),date("d")-0,date("Y")));

    $strDatum0=date("Ymd",mktime(0,0,0,date("m"),date("d"),date("Y")));
    $strDatum1=date("Ymd",mktime(0,0,0,date("m"),date("d")-1,date("Y")));
    $strDatum2=date("Ymd",mktime(0,0,0,date("m"),date("d")-2,date("Y")));
    $strDatum3=date("Ymd",mktime(0,0,0,date("m"),date("d")-3,date("Y")));

    $strFilename1 = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum1.'.js';
    $strFilename2 = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum2.'.js';
    $strFilename3 = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum3.'.js';

// DAG 0

for($i=0;$i<3;$i++) {
    if ($i == "0") {
        $strFilename = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum0.'.js';
        $strDatumList=strftime ("%e %B", mktime(0,0,0,date("m"),date("d")-0,date("Y")));
    }
    elseif ($i == "1") {
        $strFilename = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum1.'.js';
        $strDatumList=strftime ("%e %B", mktime(0,0,0,date("m"),date("d")-1,date("Y")));
    }
    elseif ($i == "2") {
        $strFilename = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum2.'.js';
        $strDatumList=strftime ("%e %B", mktime(0,0,0,date("m"),date("d")-2,date("Y")));
    }
    else {
        $strFilename = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum3.'.js';
        $strDatumList=strftime ("%e %B", mktime(0,0,0,date("m"),date("d")-3,date("Y")));
    }



if (!file_exists($strFilename)) {
    $dbcnx = mysql_connect("localhost", "*********", "********");
    mysql_select_db("*********");
    ob_start();
    for ($r=1;$r<101;$r++) {
        srand((double)microtime()*10000000);  
        $random = rand(1, 5);
        if ($random == "1") { //BLINDLINK
            $result = mysql_query("SELECT * FROM linkjes ORDER BY RAND() DESC LIMIT 0, 1");
            $num_rows = mysql_num_rows($result);
            if ($num_rows == 0) {
                $random = "2";
            }
            while ($row = mysql_fetch_array($result)) {
                $subject = $row["strOms"];
                $length=strlen($subject);
                if($length>53) {
                    $subject=substr($subject, 0, 50)."...";
                }
            echo "link(\"". $strDatumList . "\",\"". $row["strGenre"] . "\",\"" . $row["strUrl"] ."\",\"<font color=red>". $subject ."</font>\");//B\n";
            $ideetje = $row['id'];
            }
        }
        if ($random == "2") { // SPONCOR
            $result = mysql_query("SELECT * FROM linkjes WHERE strListed = '0' AND strSponcor = '1' ORDER BY 'id' DESC LIMIT 0, 1");
            $num_rows = mysql_num_rows($result);
            if ($num_rows == 0) {
                $random = "3";
            }
            while ($row = mysql_fetch_array($result)) {
                $subject = $row["strOms"];
                $length=strlen($subject);
                if($length>53) {
                    $subject=substr($subject, 0, 50)."...";
                }
                echo "link(\"". $strDatumList . "\",\"". $row["strGenre"] . "\",\"" . $row["strUrl"] ."\",\"<font color=green>". $subject ."</font>\");//$\n";
                $ideetje = $row['id'];
                mysql_query("UPDATE linkjes SET strListed = '1' WHERE id = '$ideetje';");
            }
        }
        if ($random == "3") { // REFERERS
            if ($r >= "50") {
                $result = mysql_query("SELECT * FROM linkjes WHERE strListed = '0' AND strRefer = '1' ORDER BY 'id' DESC LIMIT 0, 1");
                $num_rows = mysql_num_rows($result);
                if ($num_rows == 0) {
                    $random = "5";
                }
                while ($row = mysql_fetch_array($result)) {
                    $subject = $row["strOms"];
                    $length=strlen($subject);
                    if($length > 53) {
                        $subject=substr($subject, 0, 50)."...";
                    }
                    echo "link(\"". $strDatumList . "\",\"". $row["strGenre"] . "\",\"" . $row["strUrl"] ."\",\"<font color=yellow>". $subject ."</font>\");//@\n";
                    $ideetje = $row['id'];
                    mysql_query("UPDATE linkjes SET strListed = '1' WHERE id = '$ideetje';");
                }
            }
        }
        else {
            $result = mysql_query("SELECT * FROM linkjes WHERE strListed = '0' AND strSponcor = '0' AND strRefer = '0' ORDER BY 'id' DESC LIMIT 0, 1");
            while ($row = mysql_fetch_array($result)) {
                $subject = $row["strOms"];
                $length=strlen($subject);
                if($length > 53) {
                    $subject=substr($subject, 0, 50)."...";
                }
                echo "link(\"". $strDatumList . "\",\"". $row["strGenre"] . "\",\"" . $row["strUrl"] ."\",\"". $subject ."\");\n";
                $ideetje = $row['id'];
                mysql_query("UPDATE linkjes SET strListed = '1' WHERE id = '$ideetje';");
            }
        }
    }
    $output = ob_get_contents();
    ob_end_clean();
    $file = fopen($strFilename, "w");
    fputs($file, $output);
    fclose($file);
    mysql_close();
}
}



$dbcnx = mysql_connect("localhost", "*********", "********");
mysql_select_db("*********");
mysql_query("UPDATE linkjes SET strListed = '0'");
mysql_close();

[dusty]

Ja.

Case.

Integers als integers aanspreken niet als strings.

En het eruit halen van de links uit de database kan beter en effectiever dan een voor een in een lus.

[Gerwin]

dusty schreef op 07 July 2003 @ 00:25:
Ja.

Case.

Integers als integers aanspreken niet als strings.

En het eruit halen van de links uit de database kan beter en effectiever dan een voor een in een lus.

Je bedoeld de quotes om de cijfertjes weghalen?

En dat tweede zit ik met een probleem denk ik:
- elke link mag maar één keer gebruikt worden
- elke eerstvolgende link moet de oudste in de database zijn
- de linkjes per categorie (twee selects in de database) moeten door elkaar gemixt worden op basis van die random

Ben al wel redelijk bekend, maar zodra dingen door elkaar gaan lopen dan ben ik geen echte kei. Is dat echt mogelijk... ik ga er vannacht eens over denken, alle tips zijn welkom!

[ Voor 14% gewijzigd door Gerwin op 07-07-2003 00:39 ]

[Morrar]

Vervang sowieso zoveel mogelijk dubbele quotes door enkele quotes (dubbel wordt geïnterpreteerd dus dat is langzamer aangezien je toch al alles met . aan elkaar plakt). Doe dit sowieso altijd met strings waar geen variabelen of end of lines etc inzitten...

Op r12 - 14 maak je variabelen aan, op 24 / 28 / 32 maak je ze weer... Lijkt me dat je r12 - 14 eruit kan gooien, of kijk ik nu ergens overheen?

[Verwijderd]

PHP:

<?
if($waarde == 3) {
  echo "test";
}
?>

Kan zo:

PHP:

<?
if($waarde == 3) echo "test";
?>

[ Voor 19% gewijzigd door Verwijderd op 07-07-2003 06:49 ]

[Verwijderd]

Oja, dusty bedoelt met case een switch statement:

PHP:

switch($random) {
  case 1:
  // php-blaat als random 1 is
  break;
  case 2:
  // php-blaat als random 2 is
  break;
}

Daarnaast zie ik dat je 2 keer connectie maakt naar een database. Ik neem wel aan dat dit verschillende databases zijn, anders is ook dit totaal onnodig..

[ Voor 5% gewijzigd door Verwijderd op 07-07-2003 06:54 ]

[Soultaker]

Optimaliseren impliceert het inruilen van leesbaarheid en onderhoudbaarheid van de code voor executiesnelheidswinst van het programma. Een goede grondwet in de informatica is dat je dat nooit moet doen tenzij van kritiek belang is.

Natuurlijk heb ik geen enkel probleem met een topic als dit, waarin optimalisaties beschreven worden, maar om even praktisch te denken, vraag ik me wel af of je de optimalisaties wel nodig hebt. Heb je benchmarks gedaan op je site en is deze te traag? Ligt dat aan jouw script of aan de server? Is het ueberhaupt je eigen server en is de load dermate hoog dat dit script een bottleneck vormt? Als dit allemaal niet het geval is, is optimaliseren dan niet gewoon zonde van de tijd en moeite? Hoe vaak wordt het script per dag eigenlijk aangeroepen; minder dan 1000? Dan zou ik niet eens de moeite nemen het te optimaliseren (of de executie moet secondenlang duren, wat me niet waarschijnlijk lijkt).

Uiteraard is het altijd leerzaam om programmacode of een executieplatform beter te leren kennen en ik wil dan ook niemand ontmoedigen om dit te proberen, maar doe het dan met het doel er wat van te leren in plaats van "optimalere" code te verkrijgen, want dat is in praktijk waarschijnlijk een illusie.

edit:
En nu nog een inhoudelijke reactie. Als je dan toch gaat optimaliseren, maak dan onderscheid tussen wezenlijke verschillen en marginale wijzigingen. Het omschrijven van double-quoted-strings naar geconcateneerde single-quoted-strings levert in een programma als dit praktisch geen snelheidswinst op, net als het weghalen van accolades om blokken van een enkel statement. Dat soort dingen kun je dus wel laten, tenzij je besparen honderdduizenden keren uitvergroot kan worden, doordat de betreffende code bijvoorbeeld in een lus staat (en zelfs dan hebben optimalisaties voor de parser, die slechts eenmaal uitgevoerd wordt, geen toegevoegd nut, natuurlijk).

Wat wél wezenlijk verschil maakt is het afschaffen van onnodige SQL queries of het optimaliseren van de executie ervan. Dit scheelt niet alleen in executietijd maar ook in serverload en dat is altijd prettig. Ook op dingen als het onnodig inlezen van bestanden of het gebruik van onnodig complexe algoritmen valt te besparen, maar daar is in jouw programma geen sprake van.

[ Voor 32% gewijzigd door Soultaker op 07-07-2003 09:32 ]

[Swinnio]

Die allereeste for-loop lijkt me een beetje overbodig, aangezien alle ifs erin om de beurt worden zullen worden aangeroepen en het else-statement nooit uitgevoerd zal worden.

/edit: zie nu dat "if (!file_exists($strFilename))" ook nog in de loop hoort (indent?), hoewel daar de variabele $i niet meer van belang lijkt. Dan lijkt het me efficienter de eerste statements in de loop sequentieel uit te voeren en van het hele "if (!file_exists($strFilename))"-gebeuren een funktie te maken.

[ Voor 48% gewijzigd door Swinnio op 07-07-2003 09:38 ]

[Verwijderd]

- offtopic:

Soultaker schreef op 07 July 2003 @ 09:27:
Optimaliseren impliceert het inruilen van leesbaarheid en onderhoudbaarheid van de code voor executiesnelheidswinst van het programma. Een goede grondwet in de informatica is dat je dat nooit moet doen tenzij van kritiek belang is.

Dat zou zo zijn als je eerste stelling inderdaad waar zou zijn.
Imho is dat alleen niet zo;
optimizing kan ook best beter leesbare code opleveren.
Optimizen kan bv. door het vervangen van een algoritme door een ander.
Daar hoeft de leesbaarheid helemaal niet voor achteruit te gaan.

[mocean]

je doet nu een loopje (100x) en daarbij pak je steeds 1 record uit de database,
Als je wilt optimaliseren zou ik er in ieder geval voor zorgen dat je maar 1 query doet ipv 100

[dingstje]

Verwijderd schreef op 07 July 2003 @ 06:54:
Oja, dusty bedoelt met case een switch statement:

PHP:

switch($random) {
  case 1:
  // php-blaat als random 1 is
  break;
  case 2:
  // php-blaat als random 2 is
  break;
}

Daarnaast zie ik dat je 2 keer connectie maakt naar een database. Ik neem wel aan dat dit verschillende databases zijn, anders is ook dit totaal onnodig..

Ik dacht dat PHP een switch statement zelf omvormt naar een if-statement, wat dus zorgt voor extra parsetime?

[Mithrandir]

Verwijderd schreef op 07 July 2003 @ 09:43:
- offtopic:

[...]


Dat zou zo zijn als je eerste stelling inderdaad waar zou zijn.
Imho is dat alleen niet zo;
optimizing kan ook best beter leesbare code opleveren.
Optimizen kan bv. door het vervangen van een algoritme door een ander.
Daar hoeft de leesbaarheid helemaal niet voor achteruit te gaan.

Soultaker zegt niet dat alle optimalisaties meteen betekenen dat er slechter leesbare code van komt. Dingen als

PHP:

<? 
if($waarde == 3) echo "test"; 
?> 

Leveren echter zeker weten minder mooie en minder onderhoudbare code op. En beter leesbare code door het vervangen van een algoritme lijkt me wat dubieus, want dat zou betekenen dat je het eerste algoritme slordig hebt gecode. (Als in: niet goed leesbaar). Je kunt imho ieder stuk code goed leesbaar maken. Al heeft dat soms (al dan niet extreem) kleine tijdsverschillen...

Doe maar eens tests met een if mét en eentje zonder curly brackets... Ik zal ff tests draaien. I'll be back.

[EDIT]

Ok, tests gedraaid.

Deze code:

PHP:

<?php

include("classes/timer.class.php");
$timer = new Timer;
for($i = 0; $i < 1000000; $i++)
{
    if(true) echo ' ';
}
echo $timer->time();    

?>

Geeft de volgende resultaten:

code:

2.1464539766312
2.1188510656357
2.1551959514618
2.1629250049591
2.2290290594101

En de volgende code:

PHP:

<?php

include("classes/timer.class.php");
$timer = new Timer;
for($i = 0; $i < 1000000; $i++)
{
    if(true) 
    {
        echo ' ';
    }
}
echo $timer->time();    

?>

geeft de volgende resultaten:

code:

2.1573740243912
2.1547819375992
2.183954000473
2.2107529640198
2.0637359619141

Dit alles gedraaid op apache (1.3 volgens mij) met PHP 4.2.3 op een Celeron 1200 @ 1344 met 320 MB intern geheugen.

Je kunt dus concluderen dat het helemaal niets verschil maakt. Ik heb een poos geleden al een test gedaan met " en ' en '.' Daaruit kwam naar voren dat dat ook helemaal niets uitmaakte.
Maw: Schrijf zulke dingen gewoon op de mooiste manier, dan blijft je code het best leesbaar.

[ Voor 44% gewijzigd door Mithrandir op 07-07-2003 10:16 ]

[Soultaker]

Verwijderd schreef op 07 July 2003 @ 09:43:
optimizing kan ook best beter leesbare code opleveren.
Optimizen kan bv. door het vervangen van een algoritme door een ander.
Daar hoeft de leesbaarheid helemaal niet voor achteruit te gaan.

Dat ben ik met je eens, maar dat is eigenlijk maar een specifiek geval. In het algemeen gaat de leesbaarheid er juist op achteruit. Het geval dat jij schetst is niet alleen een optimalisatie, maar net zo goed een geval van je code beter maken.

Het beter maken van code (ofwel "refactoring" om een mooie blaatterm te gebruiken) vind ik ook heel erg nuttig en inderdaad leidt dat vaak tot prestatieverbeteringen. Het optimalisatieproces in het algemeen is er echter primair op gericht snelheidswinst te behalen en zal doorgaans geen betere code opleveren. Zelfs als dit in incidentele gevallen wel gebeurt, was dat nooit het doel van de optimalisaties.

Mithrandir schreef op 07 July 2003 @ 10:02:
Je kunt dus concluderen dat het helemaal niets verschil maakt. Ik heb een poos geleden al een test gedaan met " en ' en '.' Daaruit kwam naar voren dat dat ook helemaal niets uitmaakte.
Maw: Schrijf zulke dingen gewoon op de mooiste manier, dan blijft je code het best leesbaar.

Hoewel ik natuurlijk blij ben dat je m'n punt onderschrijft, ben ik het niet met je voorbeeldcode eens. Je illustreert namelijk de fout die ik al in m'n eerdere bericht noemde: je maakt een optimalisatie in de parsetijd (door de broncode aan te passen) en vervolgens verwacht je die optimalisatie in een langdurige executie duidelijk te kunnen maken. Dat werkt niet, aangezien beide scripts die je gaf na het parsen tot dezelfde interne representatie leiden. Het minimale verschil in parsetijd van je voorbeeld (wat al nooit meetbaar was, denk ik) valt nu zeker weg tegen de relatieve grote executietijd. Als je besparingen op de parsetijd wilt onderzoeken, dan moet je een script gebruiken wat uit veel code bestaat (desnoods door een hoop includes te gebruiken) en slechts een lage (gemiddelde) executietijd heeft.

Een testcase met enkele en dubbele quotes zou wel een goed voorbeeld geweest, omdat strings met dubbele quotes in de lus inderdaad elke iteratie geëvalueerd zouden worden. Maar je hebt gelijk: het verschil zou in zo'n geval ook minimaal (maar wel meetbaar) zijn.

[Bananeman]

Mithrandir schreef op 07 July 2003 @ 10:02:
[...]
[EDIT]

Ok, tests gedraaid.

Verbaast me niks dat er zo goed als geen verschil tussen zit. De extra curly levert eerder wat 'vertraging' op bij het parsen van de code, maar aangezien dat toch maar één keer wordt gedaan...

Die " en ', dat maakt al iets meer uit aangezien het van invloed is tijdens de uitvoering van het script, maar is ook maar marginaal. Wat al eerder hierboven is aangegeven: queries 'optimaliseren' scheelt al. Ook zoveel mogelijk laten doen door de database i.p.v. bijvoorbeeld met PHP code door resultaten lopen en er dan nog een conditional op loslaten.

[Rotjeknor]

Wat mij opvalt aan je code is dat je op diverse plaatsen een varnaam0 t/m varnaam3 gebruikt. Omdat je elke keer dezelfde code maar net de andere var nodig hebt, lijkt me beter om hiervoor een of meerdere arrays te gebruiken, en daardoorheen te lo(o)pen met je algemene code... Als ik het zo goed zo snel ff heb kunnen bekijken, verminderdt je totale code met bijna een kwart oid, terwijl het waarschijnlijk wel overzichtelijk blijft.

Voorderest zijn er vooral smaakverschillen in jouw code en layout van mn eigen code. Belangrijkste is, is dat je consequent bent, dat is al goed (-: Enige wat ik je nog aan kan raden is je sql queries te verdelen over meerdere regels. Je krijgt dan veel overzichtelijkere queries, waarbij je voor later gebruik heel makkelijk queries kan terugvinden, maar ook kan aanpassen.

Voorbeeldje:

PHP:

$query = "SELECT 
            * 
          FROM 
            linkjes 
          WHERE 
            strListed = '0' AND 
            strSponcor = '1' 
          ORDER BY 
            'id' DESC 
          LIMIT 
            0, 1
          "
$result = mysql_query($query);

Het feit of je caps moet gebruiken in je query is waarschijnlijk een kwestie van smaak. Mijn redenering is altijd dat caps van vroeger komt, toen er in editors nog geen onderscheid gemaakt kon worden in code dmv kleuren.

[LuCarD]

Je loops zijn verkeerd;
Loop 1:
• is een beetje onzinnig opgebouwd met al die if's
Vervang door volgende:

PHP:

           $strFilename = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum[$i].'.js'; 
        $strDatumList=strftime ("%e %B", mktime(0,0,0,date("m"),date("d")-$i,date("Y")));

• Je maakt nu meerdere malen een nieuwe connectie aan met de db?
• meerder malen selecteer je de database?

Loop 2:
• Je voer meerder malen srand uit, dit is traag en fout!


$strFilename1 - Declared not used
$strFilename2 - Declared not used
$strFilename3 - Declared not used
$strGotd - Declared not used
$todayTitel - Declared not used

[Gerwin]

Morrar schreef op 07 July 2003 @ 00:57:
Vervang sowieso zoveel mogelijk dubbele quotes door enkele quotes (dubbel wordt geïnterpreteerd dus dat is langzamer aangezien je toch al alles met . aan elkaar plakt). Doe dit sowieso altijd met strings waar geen variabelen of end of lines etc inzitten...

Op r12 - 14 maak je variabelen aan, op 24 / 28 / 32 maak je ze weer... Lijkt me dat je r12 - 14 eruit kan gooien, of kijk ik nu ergens overheen?

Inderdaar, nu zie ik ut ook, foutje ik was zelf al bezig geweest met een optimalisatie van het script, maar ben dat vergeten weg te halen.

Verwijderd schreef op 07 July 2003 @ 06:54:
Oja, dusty bedoelt met case een switch statement:

PHP:

switch($random) {
  case 1:
  // php-blaat als random 1 is
  break;
  case 2:
  // php-blaat als random 2 is
  break;
}

Daarnaast zie ik dat je 2 keer connectie maakt naar een database. Ik neem wel aan dat dit verschillende databases zijn, anders is ook dit totaal onnodig..

maakt een switch echt zoveel uit?

Swinnio schreef op 07 July 2003 @ 09:34:
Die allereeste for-loop lijkt me een beetje overbodig, aangezien alle ifs erin om de beurt worden zullen worden aangeroepen en het else-statement nooit uitgevoerd zal worden.

/edit: zie nu dat "if (!file_exists($strFilename))" ook nog in de loop hoort (indent?), hoewel daar de variabele $i niet meer van belang lijkt. Dan lijkt het me efficienter de eerste statements in de loop sequentieel uit te voeren en van het hele "if (!file_exists($strFilename))"-gebeuren een funktie te maken.

Ik maak enkel een connectie met de database aan als ik zie nodig heb, verbreek vervolgens weer de verbinding als ik die niet nodig heb, zo krijg ik dus meerdere "make connection" en "disable connection" in het script.

Ik maak vier bestandjes in een loop maar mocht een bestandje niet bestaan moet hij hem aanmaken, ik had eerst 4 keer het script onder elkaar staan maar heb dit nu met een loop in één stuk weten te krijgen.

mocean schreef op 07 July 2003 @ 09:55:
je doet nu een loopje (100x) en daarbij pak je steeds 1 record uit de database,
Als je wilt optimaliseren zou ik er in ieder geval voor zorgen dat je maar 1 query doet ipv 100

Ja maar hoe krijg ik dat voor elkaar? Ik wil dat de linkjes gemixt worden. En ik weet op voorhand nooit met de random hoeveel ik er van elke categorie zie.

Rotjeknor schreef op 07 July 2003 @ 11:42:
Wat mij opvalt aan je code is dat je op diverse plaatsen een varnaam0 t/m varnaam3 gebruikt. Omdat je elke keer dezelfde code maar net de andere var nodig hebt, lijkt me beter om hiervoor een of meerdere arrays te gebruiken, en daardoorheen te lo(o)pen met je algemene code... Als ik het zo goed zo snel ff heb kunnen bekijken, verminderdt je totale code met bijna een kwart oid, terwijl het waarschijnlijk wel overzichtelijk blijft.

Voorderest zijn er vooral smaakverschillen in jouw code en layout van mn eigen code. Belangrijkste is, is dat je consequent bent, dat is al goed (-: Enige wat ik je nog aan kan raden is je sql queries te verdelen over meerdere regels. Je krijgt dan veel overzichtelijkere queries, waarbij je voor later gebruik heel makkelijk queries kan terugvinden, maar ook kan aanpassen.

Voorbeeldje:

PHP:

$query = "SELECT 
            * 
          FROM 
            linkjes 
          WHERE 
            strListed = '0' AND 
            strSponcor = '1' 
          ORDER BY 
            'id' DESC 
          LIMIT 
            0, 1
          "
$result = mysql_query($query);

Het feit of je caps moet gebruiken in je query is waarschijnlijk een kwestie van smaak. Mijn redenering is altijd dat caps van vroeger komt, toen er in editors nog geen onderscheid gemaakt kon worden in code dmv kleuren.

Leuk dat je meedenkt, maar het gaat me eigenlijk meer om wat het beste voor het script is. Hoe het het snelste en beste is het script te laten draaien. Kan ik dingen op een nog makkerlijkere manier doen, zoals ik hierboven al zei had ik eerst een aantal keer een soort van "copie and paste" onder elkaar, dat heb ik al ingekort. Maar ik heb de indruk dat het nog beter kan.

LuCarD schreef op 07 juli 2003 @ 11:52:
Je loops zijn verkeerd;
Loop 1:
• is een beetje onzinnig opgebouwd met al die if's
Vervang door volgende:

PHP:

           $strFilename = '/home/httpd/vhosts/*********.nl/httpdocs/cache/T'.$strDatum[$i].'.js'; 
        $strDatumList=strftime ("%e %B", mktime(0,0,0,date("m"),date("d")-$i,date("Y")));

• Je maakt nu meerdere malen een nieuwe connectie aan met de db?
• meerder malen selecteer je de database?

Loop 2:
• Je voer meerder malen srand uit, dit is traag en fout!


$strFilename1 - Declared not used
$strFilename2 - Declared not used
$strFilename3 - Declared not used
$strGotd - Declared not used
$todayTitel - Declared not used

Ik moet toch een loop hebben om de daten uit te kunnen lezen, dit heb ik juist gedaan omdat ik anders 4 keer grotendeels hetzelfde stuk code onder elkaar moet hebben bij de verschillende dagen.

Ik maak een connectie met de database als ik die nodig heb, dan verbreek ik 'm weer als ik hem niet nodig heb, is dat niet nodig?

Die overige devinities bovenaan worden gebruikt op de site zelf, bijvoorbeeld voor "Het is vandaag .... ".

[stekkel]

Als ik ff vluchtig naar je code kijkt valt het me op dat je ongeveer 400 sql queries uitvoerd gebaseerd op de uitkomst van random. Is het niet handiger om daar 1 query van te maken en dan met de results aan de slag en dan randomize toe te passen?

Bovendien open je 4 mysql connecties (vanwege de eerste for lus) en dat is IMHO niet echt slim. 1 connectie is voldoende. Net zoals een database selectie.

Laatste opmerking, ik heb wel eens gehoord dat ++$i sneller is dan $i++. Volgens mij heb ik het ook wel eens getest en bleek het echt zo te zijn. Ik gebruik in ieder geval standaard ++$i als increment methode.

[ Voor 21% gewijzigd door stekkel op 08-07-2003 00:17 . Reden: increment opmerking ]

[Verwijderd]

Mja, alleen hebben ++$i en $i++ wel een andere betekenis...

Another good example of expression orientation is pre- and post-increment and decrement. Users of PHP/FI 2 and many other languages may be familiar with the notation of variable++ and variable--. These are increment and decrement operators. In PHP/FI 2, the statement '$a++' has no value (is not an expression), and thus you can't assign it or use it in any way. PHP enhances the increment/decrement capabilities by making these expressions as well, like in C. In PHP, like in C, there are two types of increment - pre-increment and post-increment. Both pre-increment and post-increment essentially increment the variable, and the effect on the variable is idential. The difference is with the value of the increment expression. Pre-increment, which is written '++$variable', evaluates to the incremented value (PHP increments the variable before reading its value, thus the name 'pre-increment'). Post-increment, which is written '$variable++' evaluates to the original value of $variable, before it was incremented (PHP increments the variable after reading its value, thus the name 'post-increment').

okee toegegeven, als je alleen $i++ ofzo gebruikt en deze waarde niet direct aan een variabele toekent maakt het niet uit...

[Verwijderd]

In principe doen $i++ en ++$i hetzelfde alleen het verschil zit hem in het resultaat. Bij $i++ wordt eerst de waarde teruggegeven en daarna de incremement toegepast. Voorbeeld:

PHP:

<?
$i = 3;
echo $i++; // resulteerd in 3
echo ++$i; // resulteerd in 4
?>

[Verwijderd]

LuCarD schreef op 07 July 2003 @ 11:52:

$strFilename1 - Declared not used
$strFilename2 - Declared not used
$strFilename3 - Declared not used
$strGotd - Declared not used
$todayTitel - Declared not used

Tikkeltje OT, maar toch.

Misschien een beetje wishfull thinking, maar gebruik jij een tooltje om bovenstaande te retourneren? Zo ja, welke? en waar vind ik dat?

[Verwijderd]

Error_reporting E_ALL.
geeft deze waarden weer. Als je PHP aan het developen bent zet deze dan aan.
Je haalt veel meer fouten uit je PHP script.
Staat dit niet aan, dan negeert PHP deze waarden gewoon.

toch !?

[Verwijderd]

Verwijderd schreef op 08 July 2003 @ 11:22:
Error_reporting E_ALL.
geeft deze waarden weer. Als je PHP aan het developen bent zet deze dan aan.
Je haalt veel meer fouten uit je PHP script.
Staat dit niet aan, dan negeert PHP deze waarden gewoon.

toch !?

Dat weet ik, en wees gerust: al mijn code wordt E_ALL-proof geschreven. Echter, ik wil dit niet 'runtime' weten, maar 'compile time'. Dus dat wanneer ik een testsuite op m'n code loslaat deze suite mij kan vertellen of ik niet nutteloze dingen in m'n code heb staan. Bij een wat grotere codebase wil je het overzicht nog wel eens verliezen.

Ik weet bijna zeker dat een dergelijke tool nog niet bestaat, but there's always hoping.

-Edit: Even indekken. Ik ben me er zeer van bewust dat PHP code in principe niet 'gecompileerd' wordt. Als in, naar 'standalone uitvoerbare vorm'. PHP heeft echter zeer zeker wel een 'compile' stadium. In dit stadium wordt PHP code omgezet naar Zend oparrays. -/edit-

[ Voor 19% gewijzigd door Verwijderd op 08-07-2003 11:47 ]

[Verwijderd]

-edit: Krijg eerst 3x bij een quote "same message" en dan opeens een echte double post?? Werkt goed, die controle! -

[ Voor 82% gewijzigd door Verwijderd op 08-07-2003 11:32 ]

[MisterData]

Verwijderd schreef op 07 July 2003 @ 06:48:

PHP:

<?
if($waarde == 3) {
  echo "test";
}
?>

Kan zo:

PHP:

<?
if($waarde == 3) echo "test";
?>

En waarom is dat sneller? Dan kun je net zo goed zoiets doen:

PHP:

$waarde==3?echo "test":echo "";

[Verwijderd]

of gewoon

PHP:

$waarde==3 && printf('waarde is 3 :-)');

=edit=
En spreek je integers idd alsjeblieft aan als integers en niet als strings...

Dus

PHP:

// FOUT:
$integertje = "5";
$integertje++;

// GOED:
$integertje = 5;
$integertje++;

[ Voor 73% gewijzigd door Verwijderd op 08-07-2003 13:11 ]

[LuCarD]

MisterData schreef op 08 juli 2003 @ 12:57:
[...]


En waarom is dat sneller? Dan kun je net zo goed zoiets doen:

PHP:

$waarde==3?echo "test":echo "";

Als we toch aan het mieren neuken zijn doe het dan zo

PHP:

echo $waarde==3?"3":"geen drie";

[ Voor 9% gewijzigd door LuCarD op 08-07-2003 13:34 ]

[SiErRa]

Nou we toch over die if bezig zijn, het is niet echt een optimalisatie, maar wel een handige tip:

Niet:

PHP:

if($waarde == 3) { 
  echo "test"; 
}

Wel:

PHP:

if(3 == $waarde) { 
  echo "test"; 
}

De reden hiervoor, iedereen vergeet wel eens een =, en aangezien het geen error veroorzaakt in de "niet" versie kan je je rot zoeken tijdens het debuggen.

[ Voor 16% gewijzigd door SiErRa op 08-07-2003 14:48 ]

[Verwijderd]

wat een gelul over haakjes, als je t over performance hebt kun je beter kijken naar de code.
de hoeveelheid functies die dubbel aangeroepen wordt maar dezelfde waarde verwachten, etc

t is maar een idee

[Verwijderd]

PHP:

<?
<?
if(3 == $waarde) { 
  echo "test"; 
}
?> 

Ik heb nog nooit iemand op deze manier if-statements zien behandelen. Het is stukken overzichtelijker wanneer je gewoon de haakjes correct schrijft in combinatie met $waarde == 3

[ Voor 25% gewijzigd door Verwijderd op 08-07-2003 16:10 ]

[ACM]

Verwijderd schreef op 08 July 2003 @ 14:48:
wat een gelul over haakjes, als je t over performance hebt kun je beter kijken naar de code.
de hoeveelheid functies die dubbel aangeroepen wordt maar dezelfde waarde verwachten, etc

t is maar een idee

't Aantal queries dat uitgevoerd wordt wil ook nog wel eens significant te verminderen zijn

[Gerwin]

ACM schreef op 08 July 2003 @ 16:10:
[...]

't Aantal queries dat uitgevoerd wordt wil ook nog wel eens significant te verminderen zijn

Inderdaad daar ging het mij in de eerste instantie ook om, hoewel het ook interressant is te leven hoe je het beste een haakje of quot kunt zetten in je script, echter: hoe kun je die SELECT query's dan anders beter doen. Zoals ik eerder weer kan ik niet van te voren weten hoevaak is een linkje van een bepaalde categorie nodig heb. Dus zou ik dat op voorhand moeten doen, maar dan nog blijf ik zitten met twee selects die door elkaar en om willekeurig gemixt moeten worden. Iemand op dit punt een suggestie?

[Crazy D]

Verwijderd schreef op 08 juli 2003 @ 16:09:Ik heb nog nooit iemand op deze manier if-statements zien behandelen. Het is stukken overzichtelijker wanneer je gewoon de haakjes correct schrijft in combinatie met $waarde == 3

Het voorkomt rare bij-effecten (bugs...) als je per ongeluk = in plaats van == typt.

[Hein]

Je kan de database ook ontlasten door ivp "select * from..." alleen de veldnamen te selecteren die je daadwerkelijk nodig hebt. Dit scheelt best wel op het moment dat je veel loopjes hebt met een database query

[Verwijderd]

Crazy D schreef op 08 July 2003 @ 19:24:
[...]

Het voorkomt rare bij-effecten (bugs...) als je per ongeluk = in plaats van == typt.

Het is geen bij-effect of bug, het is gewoon een semantische fout je die je maakt.

PHP:

if($test == 3) echo "test"; // correcte statement
// omdat het assigment ($test = 3) 3 (en dus geen 0 dus true) oplevert..
// is dit
if($test = 3) echo "test"; 
// hetzelfde als dit
if(true) echo "test";

Als je deze fout maakt resulteert je if-statement dus altijd true.

[ Voor 8% gewijzigd door Verwijderd op 09-07-2003 09:57 ]

[Verwijderd]

Ja, dat is ook het idee erachter. Je kunt die semantische fout maken, wat tot bugs in jouw script leidt. Als je de vaste waarde 3 eerst gebruikt in je if-statement zorg je er voor dat je geen 'assignment' kunt doen. Als je $variabele aan 3 probeert te wijzen krijg je gewoon een parse error, andersom niet. Daar evalueert het tot TRUE (gegeven dat het niet om 0 gaat). Door Crazy D's methode te gebruiken openbaart de fout zich dus.

[Gerwin]

Hein schreef op 08 juli 2003 @ 19:35:
Je kan de database ook ontlasten door ivp "select * from..." alleen de veldnamen te selecteren die je daadwerkelijk nodig hebt. Dit scheelt best wel op het moment dat je veel loopjes hebt met een database query

En als ik alles uit de database wil selecteren is het dan beter om toch alle velden afzonderlijk te noemen of voldoet een * dan voor de performance net zo goed?

Is er ook een manier om een loop te voorkomen en toch verschillende selects random te mengen?

[Soultaker]

Gerwin schreef op 09 July 2003 @ 18:42:
En als ik alles uit de database wil selecteren is het dan beter om toch alle velden afzonderlijk te noemen of voldoet een * dan voor de performance net zo goed?

Ik kan me niet voorstellen dat het expliciet noemen van alle velden merkbaar trager is, aangezien dit weer typisch een voorbeeld is van een parse-optimalisatie. Je query wordt maar één keer geparsed en dan maakt het niet veel uit of de SQL server "*" of "a,b,c,d,e" moet parsen. Een andere goede reden om juist wel de gewenste velden expliciet te noemen, is dat je fouten zo vroeg mogelijk af kunt vangen. Als je je databasemodel aanpast waardoor veld 'a' opeens anders heet, is het vervelend als PHP daar overal impliciet 0 of undefinied (afhankelijk van de context) van maakt (zoals by default gebeurt). Door de velden expliciet te noemen weet je dat als je query geslaagd is, je ook exact die velden binnenkrijgt.

Is er ook een manier om een loop te voorkomen en toch verschillende selects random te mengen?

Kun je dat misschien even toelichten? Wat voor 'loops' denk je zoal aan?

[Gerwin]

Met die loopt bedoel ik die zoals ik die in mijn eerste post van dit topic heb gedaan, ik wil een lijstje hebben met 100 linkjes onder elkaar en dat uit verschillende categorieren. Ik maak dan random een cijfer aan en op basis van dat cijfer haal ik telkens één linkjes uit de database waarna door middel van een for loop een volgend random cijfer bepaald word en opnieuw één linkje gehaald word. Elk linkje mag maar één keer voorkomen en na het selecteren van de link maak ik een veld een "1" ipv de "0" die er standaard staat wat dus betekend dat hij "gelist" geweest is. Ik heb nu zegmaar 6 dagen (dus 6 x 100 linkjes), 600 links op een site staan, de linkjes totaal worden er dus 600 SELECTS uitgevoerd en 600 UPDATE query's.

[Gerwin]

Niemand een idee? Is het wel mogelijk?

[Grijze Vos]

Die accolades gebruiken of niet gebruiken is meer iets van stijl, dan van optimalisatie. Al die kleine opmerkingen zijn futiel. Wat boeit het verschil tusse ++$i en $i++ nou. Ervaring leert ons dat 90% van de uitvoer-tijd hem meestal zit in een paar kleine lussen.

Je kunt het beste kijken naar je lussen lijkt me. Je hebt een while-lus om een enkele rij die je uitlesst, niet echt handig, probeer een query te verzinnen met 100 resultaten, en gebruik daar die while lus bij. Alhoewel dat misschien de random-heid van je linkjes niet ten goede komt. Dan moet je dubbele resultaten waarschijnlijk achteraf weer eruit vissen...

[Devilfish]

mysql kent de optie om order by random te gebruiken (precieze code moet je maar ff opzoeken op mysql site), met een limit er bij kun je zo gemakelijk 100 verschillende resultaten genereren, welke je dan weer verder kunt gebruiken.

[Gerwin]

Ik kan wel 100 resultaten selecteren en die dan random orderen dmv RAND() echter ik wil precies kunnen instellen hoeveel tijd van de kans ik een bepaalde categorie linken wil hebben. Zo moet ik dus een lijst selecteren en vervolgens een andere selectie doen voor een volgende categorie... die ook weer berekend moet worden. Hoe kun je twee selecties door elkaar husselen?