[PHP/MySQL] Parsetime van 3 seconden normaal?

[Ras]

Voor het bedrijfje van mijn ouders heb ik een php/mysql-systeempje gemaakt waar ze klanten in kunnen voeren en aan kunnen geven wat die klanten huren. Alle producten die te huur zijn komen in een tabel te staan waarin te zien is of een product nog beschikbaar is op een bepaalde datum.

zie screenshot:


Deze pagina bestond eerst uit een php loop waarin circa 2000 queries aangeroepen werden. De pagina deed er 4 tot 4,5 seconden over om te parsen. Ik veronderstelde dat dit nogal lang is en besloot de code te herschrijven.

De 2000 queries teruggebracht tot 1 enkele query die zijn gegevens uit 3 verschillende databasetabellen haalt. PHP code er bij geschreven en de nieuwe parsetime is: 2,5 à 3 seconden! Goed nieuws, het is minder geworden, maar is dit normaal voor een dergelijke pagina of moet ik eens met de host gaan praten? Er staan circa 70 producten in de lijst.

[b19a]

Haal je code eens door een profiler (bv. xdebug) en kijk waar de meeste tijd in gaat zitten. Mogelijk leun je nu teveel op code om je data te verzamelen. Probeer een evenwicht tussen code en database te vinden.

Allicht kun je wat (pseudo-)code posten om ons mee te laten denken.

[HuHu]

Hoe lang doet je query er zelf over? Dus alleen de query, zonder de PHP code die er omheen zit. Dan kun je al snel zien of je de query moet optimaliseren, of dat er iets geks gebeurd in PHP.

[Juup]

Een paar rake indices op de database kunnen soms veel schelen.

[Ras]

Ik heb even gechecked hoe lang de query er zelf over doet: 0.08916 secs.

[HuHu]

Ras schreef op vrijdag 13 maart 2009 @ 18:55:
Ik heb even gechecked hoe lang de query er zelf over doet: 0.08916 secs.

Is dat zonder caching?

[Janoz]

Zonder een stukje query, database model en/of code is er natuurlijk 0 komma nada te zeggen over waar de oorzaak van de vertraging ligt.

[ACM]

Janoz schreef op vrijdag 13 maart 2009 @ 19:13:
Zonder een stukje query, database model en/of code is er natuurlijk 0 komma nada te zeggen over waar de oorzaak van de vertraging ligt.

Inderdaad, maar desalniettemin is het vermoeden van Ras dat 2 seconde nog steeds veel is voor een pagina we juist. Gebruikers willen liefst niet hoeven te wachten.

Met wat tactisch plaatsen van microtime-calls kan je overigens ook al een hoop "profiling" informatie achterhalen, zonder gelijk moeilijk te moeten doen met ondersteuning voor profilers (zeker als je van een hoster afhankelijk bent nogal onhandig) die bovendien zelf ook weer vertraging introduceren.

[Ras]

@Huhu: Ja, zonder caching. Het is ook niet zo dat een parsetime van 3 seconden vervelend is voor het huidige gebruik. Er maken slechts 3 personen gebruik van die samen niet vaker dan 30 keer op een dag die pagina tevoorschijn toveren. Ik ben echter wel benieuwd of het efficiënter behoord te zijn, zodat ik er van kan leren.

Janoz schreef op vrijdag 13 maart 2009 @ 19:13:
Zonder een stukje query, database model en/of code is er natuurlijk 0 komma nada te zeggen over waar de oorzaak van de vertraging ligt.

Dat ben ik met je eens en ik zal dan ook spoedig wat meer info daarover geven. Maar zoals de poster na je al had aangegeven was mijn vraag voornamelijk of de parsetime van 3 seconden normaal is.

De conclusie die ik nu trek uit de reacties is dat 3 seconden te veel is voor mijn pagina en dat het probleem niet bij de host en niet bij de query gezocht moet worden, maar bij de php code.

Ik ben inmiddels wel benieuwd hoe ik mijn code kan verbeteren en zal dan ook wel wat code gaan posten. Alvast bedankt voor jullie reacties! Nu eerst ff eten

[ Voor 17% gewijzigd door Ras op 13-03-2009 19:38 ]

[Zoijar]

3 seconden is erg veel ja; brakke code en/of query.

[ Voor 32% gewijzigd door Zoijar op 13-03-2009 21:33 ]

[Bart Brinkman]

Zoijar schreef op vrijdag 13 maart 2009 @ 21:33:
3 seconden is erg veel ja; brakke code en/of query.

Of het gebrek aan een goede index...

[FireDrunk]

ik zou iig even een timestamp uit laten printen voor en na je query... dan kan je iig kijken waar de meeste tijd in gaat zitten...
Want een for loopje over 2000 items en dan nog een for loopje doen op welk vakje kan bijvoorbeeld ook al gauw 2 seconden opleveren...

[danslo]

Bart Brinkman schreef op vrijdag 13 maart 2009 @ 21:41:
[...]


Of het gebrek aan een goede index...

Dat is het dus niet, gezien deze post:
Ras in "\[PHP/MySQL] Parsetime van 3 seconden nor..."

Relevante stukken PHP posten dus.

[Ras]

Ok, niet meer nodig om te raden wat de parsetime zo slecht maakt. Hier is het stuk code wat er 2 à 2,5 seconden over doet om te parsen:

PHP:

<?
//Alle producten langslopen en een rij van weergeven
$p = 0; // variabele om om de 15 rijen de dagen vd week aan te geven
for($i = 0; $i < $num_rows; $i++){
    if($i == 0 OR $product_id[$i] != $product_id[$i-1]){
        
        // rij met dagen vd week neerzetten na iedere 15 regels
        if($p == 16){$p = 0; echo $maandrow;}
        $p++;
        
        echo("
            <tr>
                <td width=\"30\">$code[$i]</td>
                <td width=\"150\">$naam[$i]</td>
        ");
        //Alle dagen van de week weergeven voor product[i]
        $j = $i;
        for($k = 1; $k < $dagen_in_maand; $k++){                        //loop alle dagen langs voor product i
            $weekdag = date ("w", mktime (0,0,0,$maand,$k,date("Y")));  //welke dag van de week is het (ivm achtergrondkleurtje)?
            $datum_a = mktime(0,0,0,$maand,$k,date("Y"));               //begin van de dag
            $datum_b = mktime(0,0,0,$maand,$k+1,date("Y"));             //einde van de dag

            if(($datum_a <= $van[$j] AND $van[$j] <= $datum_b)
            OR ($datum_a <= $tot[$j] AND $tot[$j] <= $datum_b)
            OR ($van[$j] <= $datum_a AND $tot[$j] >= $datum_b)){
                echo("<td class=\"beschikbaarheid_1\">&nbsp;</td>"); //rood, oftewel niet beschikbaar
                if($tot[$j] < $datum_b AND $product_id[$j] == $product_id[$j+1]){$j++;}
            } else {
                if($k == date("d") and $maand == date("m")){    //huidige dag accentueren
                    echo("<td class=\"beschikbaarheid_vandaag\">&nbsp;</td>");
                } elseif($weekdag == 6 or $weekdag == 0){       //weekend accentueren
                    echo("<td class=\"beschikbaarheid_0b\">&nbsp;</td>");
                } else {
                    echo("<td class=\"beschikbaarheid_0\">&nbsp;</td>"); //wit
                }
            }
        }
        echo("
            </tr>
        ");
    }
}
?>

Om mijn code nog wat beter te begrijpen:

Uit de query haalt ie een aantal arrays:
- $van[$i] (huur vanaf deze datum)
- $tot[$i] (huur tot deze datum)
- $product_id[$i] (dûh)
- $code[$i] (productcode)
- $naam[$i] (productnaam)

Elk product komt tenminste 1 keer voor in de tabel die de query genereerd. Wanneer een product vaker in een maand word verhuurd komt ie 1x voor, per keer dat het verhuurd word.

Brand los.

[ Voor 9% gewijzigd door Ras op 13-03-2009 22:00 ]

[FireDrunk]

for loop in for loop, en daarin mktime... dat duurt wel even ja

die $p kun je eruit slopen door " if ($i % 15 == 0)" te gebruiken...

misschien een raar id, maar kan je niet beter eerst het veld maken in een array, daarna pas uit je db alles in 1 keer ophalen, en in 1 for loop op de goede plek in de array het vakje verkleuren... dus bijvoorbeeld:

code:

Boolean[][] gebruik = new Boolean[aantalproducten][31(aantaldagen)];

$meuk = query();

for ($bezetting in $result)
{
gebruik[productid][$bezetting->datum] = true;
}

printArray();

Mocht je het per dag willen specificeren...

code:

Boolean[][] gebruik = new Boolean[aantalproducten][31(aantaldagen)][dagdelen];

$meuk = query();

for ($bezetting in $result)
{
gebruik[productid][$bezetting->datum][$bezetting->dagdeel] = true;
}

printArray();

[ Voor 115% gewijzigd door FireDrunk op 13-03-2009 22:07 ]

[GlowMouse]

Grote kans dat je HTML-output erg groot is, en dat PHP op een bepaald moment wacht met de verdere uitvoering van je script totdat de client de output tot dan toe heeft ontvangen. Wat gebeurt er als je dezelfde pagina met wget vanaf de server zelf opvraagt?

thijs_cramer schreef op vrijdag 13 maart 2009 @ 21:58:
for loop in for loop, en daarin mktime... dat duurt wel even ja

We hebben het over 4000 calls naar mktime, dat duurt echt niet zolang.duurt wel vrij lang dus (1.2s op een Sempron 2800+). De cachingoplossing van $datum_a en $datum_b zoals MeAngry (onder) voorstelt, zou dus al veel uitmaken.

[ Voor 46% gewijzigd door GlowMouse op 13-03-2009 22:22 ]

[--MeAngry--]

Als het echt de PHP executie is die zo lang duurt, zou ik eens proberen om $weekdag, $datum_a en $datum_b vantevoren eenmalig uit te rekenen, in array's stoppen, en vervolgens alleen nog maar even ophalen per product.
Je bent nu voor X producten, X aantal keren hetzelfde aan het doen.

Het probleem zou dan wel echt in mktime() moeten zitten, want ik zie verder geen erg gekke dingen. Heb je het geheel al eens lokaal proberen te testen? Wat doet het daar? Want misschien word je wel gigantisch belemmerd door de host die gewoon teveel users op 1 bak draait.

[ Voor 32% gewijzigd door --MeAngry-- op 13-03-2009 22:12 ]

[FireDrunk]

--MeAngry-- schreef op vrijdag 13 maart 2009 @ 22:10:
Als het echt de PHP executie is die zo lang duurt, zou ik eens proberen om $weekdag, $datum_a en $datum_b vantevoren eenmalig uit te rekenen, in array's stoppen, en vervolgens alleen nog maar even ophalen per product.
Je bent nu voor X producten, X aantal keren hetzelfde aan het doen.

Het probleem zou dan wel echt in mktime() moeten zitten, want ik zie verder geen erg gekke dingen. Heb je het geheel al eens lokaal proberen te testen? Wat doet het daar? Want misschien word je wel gigantisch belemmerd door de host die gewoon teveel users op 1 bak draait.

offtopic:
^^ Wat hij zegt ^^

[GlowMouse]

Ras schreef op vrijdag 13 maart 2009 @ 18:55:
Ik heb even gechecked hoe lang de query er zelf over doet: 0.08916 secs.

Query + explain output?

[Ras]

De winnende oplossing

--MeAngry-- schreef op vrijdag 13 maart 2009 @ 22:10:
Als het echt de PHP executie is die zo lang duurt, zou ik eens proberen om $weekdag, $datum_a en $datum_b vantevoren eenmalig uit te rekenen, in array's stoppen, en vervolgens alleen nog maar even ophalen per product.
Je bent nu voor X producten, X aantal keren hetzelfde aan het doen.

Het probleem zou dan wel echt in mktime() moeten zitten, want ik zie verder geen erg gekke dingen. Heb je het geheel al eens lokaal proberen te testen? Wat doet het daar? Want misschien word je wel gigantisch belemmerd door de host die gewoon teveel users op 1 bak draait.

Het onderstaande stuk code doet er nog slechts een halve seconde over om te parsen. Een verbetering van 2 seconden dus.

PHP:

<?
for($k = 1; $k < $dagen_in_maand; $k++){                            //loop alle dagen langs voor product i
    $weekdag[$k] = date ("w", mktime (0,0,0,$maand,$k,date("Y")));  //welke dag van de week is het (ivm achtergrondkleurtje)?
    $datum_a[$k] = mktime(0,0,0,$maand,$k,date("Y"));               //begin van de dag
    $datum_b[$k] = mktime(0,0,0,$maand,$k+1,date("Y"));
}

//Alle producten langslopen en een rij van weergeven
$p = 0; // variabele om om de 15 rijen de dagen vd week aan te geven
for($i = 0; $i < $num_rows; $i++){
    if($i == 0 OR $product_id[$i] != $product_id[$i-1]){
        
        // rij met dagen vd week neerzetten na iedere 15 regels
        if($p == 16){$p = 0; echo $maandrow;}
        $p++;
        
        echo("
            <tr>
                <td width=\"30\">$code[$i]</td>
                <td width=\"150\">$naam[$i]</td>
        ");
        //Alle dagen van de week weergeven voor product[i]
        $j = $i;
        for($k = 1; $k < $dagen_in_maand; $k++){                        //loop alle dagen langs voor product i
            if(($datum_a[$k] <= $van[$j] AND $van[$j] <= $datum_b[$k])
            OR ($datum_a[$k] <= $tot[$j] AND $tot[$j] <= $datum_b[$k])
            OR ($van[$j] <= $datum_a[$k] AND $tot[$j] >= $datum_b[$k])){
                echo("<td class=\"beschikbaarheid_1\">&nbsp;</td>"); //rood, oftewel niet beschikbaar
                if($tot[$j] < $datum_b[$k] AND $product_id[$j] == $product_id[$j+1]){$j++;}
            } else {
                if($k == date("d") and $maand == date("m")){    //huidige dag accentueren
                    echo("<td class=\"beschikbaarheid_vandaag\">&nbsp;</td>");
                } elseif($weekdag[$k] == 6 or $weekdag[$k] == 0){       //weekend accentueren
                    echo("<td class=\"beschikbaarheid_0b\">&nbsp;</td>");
                } else {
                    echo("<td class=\"beschikbaarheid_0\">&nbsp;</td>"); //wit
                }
            }
        }
        echo("
            </tr>
        ");
    }
}
?>

Hele pagina geladen in 0.55985 secs.

thijs_cramer schreef op vrijdag 13 maart 2009 @ 21:58:
die $p kun je eruit slopen door " if ($i % 15 == 0)" te gebruiken...

Bedankt voor de tip, maar dat kan niet. $i staat niet altijd gelijk aan een nieuwe regel.

Edit: Door het inzicht dat mktime() nogal wat tijd kost als het 2000 keer word aangeroepen op een pagina, heb ik mij bedacht dat dit bij date() ook wel eens het geval zou kunnen zijn. Daarom heb ik date("m") en date("d") ook maar eens in een variabele gestopt voor de loops. Dit resulteerde erin dat de parsetime van de gehele pagina is teruggebracht van 0,55 sec naar 0,25 sec.

[ Voor 10% gewijzigd door Ras op 13-03-2009 22:46 ]

[WouZz]

Ook weer wat geleerd. PS: doe die date("Y") dan ook nog ff

[Verwijderd]

Ik denk ook even mee, misschien kan de parsetijd nog omlaag.

GlowMouse schreef op vrijdag 13 maart 2009 @ 22:25:
[...]

Query + explain output?

Wat is hier uitgekomen?
Tevens gaat hij dit

PHP:

if($i == 0 OR $product_id[$i] != $product_id[$i-1]){

net zoveel keer doen als er rows uit de query komen. Ik denk dat daar nog snelheidswinst te behalen is.

[Woy]

Ras schreef op vrijdag 13 maart 2009 @ 22:30:
Het onderstaande stuk code doet er nog slechts een halve seconde over om te parsen. Een verbetering van 2 seconden dus.

offtopic:
Ik denk dat je het over execution time hebt, het parsen van het script zal waarschijnlijk niet zo lang duren.

[NMe]

Verwijderd schreef op zaterdag 14 maart 2009 @ 10:26:
Ik denk ook even mee, misschien kan de parsetijd nog omlaag.


[...]


Wat is hier uitgekomen?
Tevens gaat hij dit

PHP:

if($i == 0 OR $product_id[$i] != $product_id[$i-1]){

net zoveel keer doen als er rows uit de query komen. Ik denk dat daar nog snelheidswinst te behalen is.

Die vergelijking moet hij toch ook gewoon voor elke row maken?

[Saven]

Bart Brinkman schreef op vrijdag 13 maart 2009 @ 21:41:
[...]


Of het gebrek aan een goede index...

Met indexes kan het nog steeds sloom gaan.

Mijn forum-index (wordt tegewoordig wel serverside gecache't als plain html) doet er zo'n 6 seconden over om te genereren. Met meer dan 100.000 posts.

Of doe ik eigenlijk iets verkeerd en moet dit in 1 seconde ook kunnen

(lichtelijk offtopic vraag )

[ Voor 4% gewijzigd door Saven op 14-03-2009 18:46 ]

[CoolGamer]

Saven schreef op zaterdag 14 maart 2009 @ 18:45:
[...]

Met indexes kan het nog steeds sloom gaan.

Mijn forum-index (wordt tegewoordig wel serverside gecache't als plain html) doet er zo'n 6 seconden over om te genereren. Met meer dan 100.000 posts.

Of doe ik eigenlijk iets verkeerd en moet dit in 1 seconde ook kunnen

(lichtelijk offtopic vraag )

Zoek eens op "database index" i.p.v. forumindex. Dat zijn totaal verschillende dingen. Dus misschien kan er met een databaseindex wel wat tijd af van dat genereren.

Maar het zou natuurlijk ook gewoon kunnen dat je niet de juiste indexen hebt gekozen. Want 100.000 is niet zo heel veel.

[ Voor 9% gewijzigd door CoolGamer op 14-03-2009 18:52 ]

[NMe]

Saven schreef op zaterdag 14 maart 2009 @ 18:45:
[...]

Of doe ik eigenlijk iets verkeerd en moet dit in 1 seconde ook kunnen

(lichtelijk offtopic vraag )

Ten eerste is daar zonder datamodel inclusief gezette indices en zonder relevante queries niets over te zeggen, en ten tweede is dit je reinste topickaping en dus niet de bedoeling hier. Als je hier antwoord op wil hebben kun je je eigen topic openen.

[Saven]

TheCoolGamer schreef op zaterdag 14 maart 2009 @ 18:51:
[...]

Zoek eens op "database index" i.p.v. forumindex. Dat zijn totaal verschillende dingen. Dus misschien kan er met een databaseindex wel wat tijd af van dat genereren.

Maar het zou natuurlijk ook gewoon kunnen dat je niet de juiste indexen hebt gekozen. Want 100.000 is niet zo heel veel.

Haha no shit ik bedoelde forumindex-pagina en de bijbehorende database indexes.
Maari k maak straks wel een eigen topic excuzes moi voor de topic kaping

[LuCarD]

Je kan die mktime ook vervangen door 1 mktime. En dan voor alle vervolg dagen 86400 bij op tellen.

[crisp]

LuCarD schreef op zaterdag 14 maart 2009 @ 23:49:
Je kan die mktime ook vervangen door 1 mktime. En dan voor alle vervolg dagen 86400 bij op tellen.

Nee; er is ook nog zoiets als zomer/wintertijd

Het kan wel met 1 mktime() (en 1 date()) in de loop die nu het dagnummer en start/end timestamps per dag doet, maar dat is nu een functie met maar [dagen per maand] iteraties dus dat effect zal nog maar weinig merkbaar zijn:

PHP:

$year = date('Y');
$thisday = mktime (0,0,0,$maand,1,$year);
for($k = 1; $k < $dagen_in_maand; $k++)
{
    $weekdag[$k] = date('w', $thisday);
    $datum_a[$k] = $thisday;
    $datum_b[$k] = mktime (0,0,0,$maand,$k+1,$year);

    $thisday = $datum_b[$k];
}

[ Voor 49% gewijzigd door crisp op 14-03-2009 23:56 ]

[Bpje]

Volgens mij zou dit al wat winst op moeten leveren.

PHP:

<?php

$year = date('Y');
$thisday = mktime (0,0,0,$maand,1,$year);

$dayOfTheMonth = date("d");
$month = date("m");

for($k = 1; $k < $dagen_in_maand; $k++)
{
    $weekdag[$k] = date('w', $thisday);
    $datum_a[$k] = $thisday;
    $datum_b[$k] = mktime (0,0,0,$maand,$k+1,$year);

    $thisday = $datum_b[$k];
} 


$html = '';

//Alle producten langslopen en een rij van weergeven
$p = 0; // variabele om om de 15 rijen de dagen vd week aan te geven
for($i = 0; $i < $num_rows; $i++){
    if($i == 0 OR $product_id[$i] != $product_id[$i-1]){
        
        // rij met dagen vd week neerzetten na iedere 15 regels
        if($p == 16){$p = 0; $html .= $maandrow;}
        $p++;
        
        $html .='
            <tr>
                <td width="30">'.$code[$i].'</td>
                <td width="150">'.$naam[$i].'</td>
        ';
        //Alle dagen van de week weergeven voor product[i]
        $j = $i;
        for($k = 1; $k < $dagen_in_maand; $k++){                        //loop alle dagen langs voor product i
            if(($datum_a[$k] <= $van[$j] AND $van[$j] <= $datum_b[$k])
            OR ($datum_a[$k] <= $tot[$j] AND $tot[$j] <= $datum_b[$k])
            OR ($van[$j] <= $datum_a[$k] AND $tot[$j] >= $datum_b[$k])){
                $html .= '<td class="beschikbaarheid_1">&nbsp;</td>'; //rood, oftewel niet beschikbaar
                if($tot[$j] < $datum_b[$k] AND $product_id[$j] == $product_id[$j+1]){$j++;}
            } else {
                if($k == $dayOfTheMonth and $maand == $month){    //huidige dag accentueren
                    $html .= '<td class="beschikbaarheid_vandaag">&nbsp;</td>';
                } elseif($weekdag[$k] == 6 or $weekdag[$k] == 0){        //weekend accentueren
                    $html .= '<td class="beschikbaarheid_0b">&nbsp;</td>';
                } else {
                    $html .= '<td class="beschikbaarheid_0">&nbsp;</td>'; //wit
                }
            }
        }
        $html .= '</tr>';
    }
} 
echo $html;

?>

Wat mij op viel was dat je " gebruikt ipv ' voor je echo's ' is iets sneller omdat bij " /n /t geparsed moet worden, Verder kun je proberen eerst alles in een variable op te vangen en vervolgens uit te poepen.

[ Voor 0% gewijzigd door Bpje op 18-03-2009 11:13 . Reden: was 1 echo vergeten ]

[Voutloos]

Single vs double quotes is de meest beruchte micro optimalisatie en met in begrip van de tijd die je bezig bent om 58 regels te posten is er de komende 1,42 miljoen jaar nog geen netto winst...

Dat er eerder in het topic succes geboekt is is puur toeval/gokwerk geweest. Het enige echte antwoord op de vraag waar de meeste tijd in zit is en blijft profilen, profilen profilen.

[ACM]

Bpje schreef op woensdag 18 maart 2009 @ 09:18:
Volgens mij zou dit al wat winst op moeten leveren.

De winst van het reduceren van de date/time-calls (wat doorgaans vrij dure calls zijn) zal toch echt het grootste stuk winst opleveren.

Wat mij op viel was dat je " gebruikt ipv ' voor je echo's ' is iets sneller omdat bij " /n /t geparsed moet worden,

Dat is niet de belangrijkste reden dat " sneller kan zijn dan '. Sterker nog, vziw wordt het tot exact dezelfde interne phpcode geparsed als er geen $ tussen de "s voorkomt. Maar zelfs als wel alle variabelen inline staan is het nog maar een beperkte winst. Hoewel binnen je kritieke pad ook microoptimalisaties natuurlijk forse winsten kunnen opleveren.

[Verwijderd]

Ras stelde op vrijdag 13 maart 2009 @ 18:26 een geweldige vraag

Waar vervolgens een geweldig antwoord op is gegeven. Tnx guys!

Ik programmeer zelf ook wel eens wat php en ik had een script draaien dat er 12 minuten over deed. Ik had zelfs al een mooi "bezig met laden" schermpje gemaakt voor de eindgebruiker inclusief schatting van de overgebleven tijd en % balkje dat volliep, omdat het echt schrikbarend lang duurde. Nooit in me opgekomen dat code ook efficiënter geschreven kon worden en dat de functies mktime en date in php zo langzaam waren.

Het betreffende script heeft extreem veel verwijzigen naar mktime en date, vandaar deze oplossing. een fuctie mktime_store erbij en find&replace mktime( naar mktime_store( et voila:

PHP:

function mktime_store($a,$b,$c,$d,$e,$f){
if(isset($_ENV['mktime'][$a][$b][$c][$d][$e][$f])){
return $_ENV['mktime'][$a][$b][$c][$d][$e][$f];
}
else{
$_ENV['mktime'][$a][$b][$c][$d][$e][$f] = mktime($a,$b,$c,$d,$e,$f);
return $_ENV['mktime'][$a][$b][$c][$d][$e][$f];
}
}

het bovenstaande heeft me teruggebracht van 12 naar 6 minuten.

Ik werd dolenthousiast en probeerde hetzelfde met het aanmaken van de functie date_store en deed een find&replace met date( naar date_store( et voila:

PHP:

function date_store($a,&$b = '#'){
if(isset($_ENV['date'][$a][$b])){
return $_ENV['date'][$a][$b];
}
else{
if($b == '#'){
$_ENV['date'][$a][$b] = date($a);
}
else{
$_ENV['date'][$a][$b] = date($a,$b);
}
return $_ENV['date'][$a][$b];
}
}

Het tweede stukje code heeft me teruggebracht van 6 minuten naar 40 seconden.

In totaal dus nog maar 1/12 over: van 12 minuten naar 40 seconden

Wat ik me nu afvraag is of het misschien zelfs loont om ze allemaal in sql te zetten en in 1x eruit te halen en te gebruiken op dezelfde manier...

[Voutloos]

En ook jij had gewoon moeten profilen.

Extra tip, maar dat is niet per se vanwege de performance: Gebruik een static variabele ipv het misbruiken van $_ENV of $_GLOBALS. Misschien kan je ipv het binnen de functie cachen zelfs ook gewoon in de aanroepende code oplossen, door bijvoorbeeld een invariant niet binnen een loopje steeds opnieuw uit te rekenen.

offtopic:
En 40 seconden is 1/18e van 12 minuten.

[Verwijderd]

Voutloos schreef op woensdag 18 maart 2009 @ 20:08:
En ook jij had gewoon moeten profilen.

Extra tip, maar dat is niet per se vanwege de performance: Gebruik een static variabele ipv het misbruiken van $_ENV of $_GLOBALS. Misschien kan je ipv het binnen de functie cachen zelfs ook gewoon in de aanroepende code oplossen, door bijvoorbeeld een invariant niet binnen een loopje steeds opnieuw uit te rekenen.

offtopic:
En 40 seconden is 1/18e van 12 minuten.

Tnx voor de tip het is voor nu wel even goed zo. Ik heb niet zo'n zin om al die calls aan te gaan passen (het zijn er echt heel veel) Dit was de makkelijkste manier voor nu.

offtopic:
ik had eerst 1 minuut opgeschreven, maar het bleek toch nog nèt iets sneller te zijn. Goeie toevoeging, dit is nog beter te verkopen

[Woy]

Verwijderd schreef op woensdag 18 maart 2009 @ 20:01:
[...]
Wat ik me nu afvraag is of het misschien zelfs loont om ze allemaal in sql te zetten en in 1x eruit te halen en te gebruiken op dezelfde manier...

Het zou inderdaad een oplossing kunnen zijn, om data redundant op te slaan. Je neemt dan bijvoorbeeld een extra veld in je tabel op, die de date al geformateerd opslaat. Laat overigens wel gewoon het Date field staan, want dat is de originele data.

Dit soort oplossingen moet je natuurlijk wel alleen doen, als je de bottleneck niet op een andere manier eenvoudig op kunt lossen.

Een nadeel daarvan is dat je wel minder flexibel word in je interface. Als je bijvoorbeeld straks ook in andere cultures wilt gaan formateren, is of je probleem weer terug, of je moet een hoop extra velden op gaan nemen.

Het is dus inderdaad van belang om eens te gaan profilen, of het restant van de 40 seconden executie tijd wel in mktime zit, en dat je niet ergens anders nog wat doet wat veel tijd kost.

[Grijze Vos]

Of je slaat datums gewoon als datum op en houdt je pas bezig met de representatie van die datum in de presentatie-laag van je code. Ik kan me niet voorstellen dat je datamodel en je code enigszins zinnig zijn ingedeeld als je meervoudige loops hebt waar veelvuldig mktime en date worden aangeroepen.

[Voutloos]

Juist. Meer redundantie kan als last resort een leuke optimalisatie zijn, maar hier is het gewoon overduidelijk niet de Echte Oplossing.

[Woy]

Voutloos schreef op donderdag 19 maart 2009 @ 13:21:
Juist. Meer redundantie kan als last resort een leuke optimalisatie zijn, maar hier is het gewoon overduidelijk niet de Echte Oplossing.

Het was idd niet mijn doel, om die oplossing hier als de juiste oplossing aan te dragen. Maar in sommige situaties kan het nou eenmaal nodig zijn om data redundant op te slaan.