[php] performance op verschillende machines

[js303]

hoi ik heb een scriptje dat een autocontrast op een plaatje toepast a la Photoshop's gelijknamige functie, en dat heb ik eerst lokaal getest, op een centrino met pentium-Mobile 1.6Ghz 512mb ram op winXP met php 4.3.3. De tijd om een 500x400 plaatje te berekenen kost ca. 5.8 seconden. Dit terwijl winamp en shoutcast lekker aan het streamen zijn.

daarnaast heb ik het script op onze webserver getest. dit is een dual Xeon 2.6 Ghz, 1gb ram, en kgeloof 1mb cache per processor. draait op Redhat (versie weet ik ff niet), met een SCSI raid. php 4.3.2. kortom snelle jongen.

ik heb zojuist getest omdat er verder geen bezoekers op de server zijn en er geen verdere apps draaien die cpu-kracht zuigen (kan ik checken via putty). hier kost hetzelfde script ca. 7.6 seconden. dat is zo'n 1.8 seconden langzamer!

ik snap er geen drol van. die server zou sneller moeten zijn naar mijn idee, of op zijn minst, als-ie fout geconfigureerd zou kunnen zijn (wat-ie niet is zover ik kan overzien) minstens even snel. maar langzamer!?

ok misschien is het php, en moet ik php even allebei op 4.3.3 of hoger hebben voor DE test. maar ik zou willen vragen: zijn er enorme verschillen in processoren (Xeon versus Pentium-M), OS'en, waarbij winXP gunstig eruit komt, en/of php versie / platforms??

btw dit is het script, mochten mensen willen testen (beetje rommeltje):

code:

<?php

    ini_set("precision", 12);

    // ==========================================
    // Timing functies voor script exection time
    // ==========================================

    function ss_timing_start ($name = 'default') {
        global $ss_timing_start_times;
        $ss_timing_start_times[$name] = explode(' ', microtime());
    }

    function ss_timing_stop ($name = 'default') {
        global $ss_timing_stop_times;
        $ss_timing_stop_times[$name] = explode(' ', microtime());
    }

    function ss_timing_current ($name = 'default') {
        global $ss_timing_start_times, $ss_timing_stop_times;
        if (!isset($ss_timing_start_times[$name])) {
            return 0;
        }
        if (!isset($ss_timing_stop_times[$name])) {
            $stop_time = explode(' ', microtime());
        }
        else {
            $stop_time = $ss_timing_stop_times[$name];
        }
        // do the big numbers first so the small ones arent lost
        $current = $stop_time[1] - $ss_timing_start_times[$name][1];
        $current += $stop_time[0] - $ss_timing_start_times[$name][0];
        return $current;
    }

    // ==========================================
    // settings
    // ==========================================

    ss_timing_start();

    $outlo          = 0;        // laagste output-grens
    $outhi          = 255;      // hoogste output-grens
    $skiptreshold   = 0.001;    // sla een tint over indien deze heel weinig voorkomt (default = 0.001)

    // ==========================================
    // open het originele plaatje
    // ==========================================

    $img    = imagecreatefromjpeg   ("test3.jpg");
    $imgw   = imagesx($img);
    $imgh   = imagesy($img);

    // ==========================================
    // maak een histogram van het plaatje
    // ==========================================

    for ($y = 0; $y < $imgh; $y++) {
        for ($x = 0; $x < $imgw; $x++) {
            $pxl    = imagecolorat($img, $x, $y);                                   // colorindex / rgb-waarde van pixel(x,y)
            $rgb    = imagecolorsforindex($img, $pxl);                              // rgb-waarde in array-vorm
            $gst    = $rgb['red']*0.3 + $rgb['green']*0.59 + $rgb['blue']*0.11;     // converteer naar grijswaarde
            //$gst  = round(min(255, max(0, $gst)));
            $hist[$gst]++;                                                          // tel aantal van deze grijswaardes
        }
    }

    // ==========================================
    // zoek horizontaal en verticaal bereik uit
    // ==========================================

    $mini       = 255;
    $maks       = 0;

    $totpixels  = $imgw * $imgh;
    $darkest    = 255;  // donkerste grijstint (we werken naar beneden toe)
    $lightest   = 0;    // lichtste grijstint (we werken omhoog)

    for ($v = 0; $v < 255; $v++) {
        // --------------------------------------
        // zoek bereik van aantal pixels uit
        // dus de grijswaarde die het minst voorkomt
        // en de grijswaarde die het meest voorkomt
        // --------------------------------------

        $mini = min($mini, $hist[$v]);
        $maks = max($maks, $hist[$v]);

        // --------------------------------------
        // zoek bereik van donkerste tot lichtste tint
        // --------------------------------------

        if ($hist[$v] / $totpixels < $skiptreshold) continue;   // indien een grijswaarde ZO weinig voorkomt, skip deze dan
        $darkest = min($darkest, $v);
        $lightest = max($lightest, $v);
    }

    $scale = ($maks-$mini) / 100;

    // ==========================================
    // bereken nieuwe plaatje
    // ==========================================

    $dst    = ImageCreateTrueColor  ($imgw, $imgh);
    $range  = ($outhi - $outlo) / ($lightest - $darkest);

    for ($y = 0; $y < $imgh; $y++) {
        for ($x = 0; $x < $imgw; $x++) {
            $pxl    = imagecolorat($img, $x, $y);                                   // colorindex / rgb-waarde van pixel(x,y)
            $rgb    = imagecolorsforindex($img, $pxl);                              // rgb-waarde in array-vorm
            $outr   = min($outhi, max(outlo, ($rgb['red'] - $darkest) * $range));
            $outg   = min($outhi, max(outlo, ($rgb['green'] - $darkest) * $range));
            $outb   = min($outhi, max(outlo, ($rgb['blue'] - $darkest) * $range));

            $col    = imagecolorresolve($dst, $outr, $outg, $outb);

            imagesetpixel($dst, $x, $y, $col);
        }
    }

    $fg = imagecolorallocate($dst, 0, 0, 0);
    imagestring     ($dst, 2, 2, 2, "Berekening kostte " . ss_timing_current() . " seconden.", $fg);
    header          ("Content-type: image/jpeg");
    imagejpeg       ($dst);
    imagedestroy    ($dst);

    // ==========================================
    // sluit plaatje
    // ==========================================

    imagedestroy    ($img);
    exit            ();

?>

[ Voor 8% gewijzigd door js303 op 16-03-2004 02:23 ]

[Wolfboy]

wat ik mij eigenlijk een beetje afvraag is: gebruikt die xeon wel 2 processors tegelijk ervoor?
ik denk namelijk dat met zo'n script maar 1 processor tegelijk gebruikt word.
en op dat moment is het dus 1 xeon tegen 1 pentium mobile
en zoals je misschien wel weet is de pentium mobile vergeleken andere processoren een stuk sneller (als je het per mhz bekijkt)
dus het zou heel goed kunnen dat die mobile de server inhaalt
het extra geheugen zal hierbij weinig uitmaken omdat het script maar een bepaalde hoeveelheid geheugen inneemt (en dat zal niet al te veel zijn) en de snelle hardeschijven maken ook niets uit want het is gewoon lezen (gebeurt in een paar ms) en parsen maar

misschien verklaart dat het snelheidsverschil een beetje

maar ik zou nog wel even proberen om onder exact dezelfde omstandigheden te testen

[Tachyon]

en zoals je misschien wel weet is de pentium mobile vergeleken andere processoren een stuk sneller (als je het per mhz bekijkt

True, maar die Xeon draait wel ff 1 GHz sneller. En is dan nog trager.
Volgens mij moet het ergens anders aan liggen.

Heb je de test enkele keren herhaald en kwam er steeds hetzelfde resultaat uit?

[js303]

(beetje offtopic aangezien dit topic niet over performance-optimizen van code gaat magoed misschien toch interessant):

hmmm, ik heb iig performance-winst kunnen boeken door de min en max functies te vervangen door if statements, bijv. if ($outr < $outlo) $outr = $outlo;

vreemd dat zoiets sneller is dan een max()...
en ik heb de dubbele loop ook al naar 1 teruggebracht.
maar nog steeds: mijn humble laptopje 1.6 is sneller dan een dual 2.6 xeon...

[js303]

@ wolfboy: ja daar heb je gelijk in. hij gebruikt idd maar 1 processor... maar waarom eigenlijk? hij heeft er toch 2 inzitten? zit die uit z'n neus te peuteren terwijl xeon 1 zich uit de naad werkt!?

@ tachyon: ja het scheelt idd een hele Ghz, en ik kan zien hoeveel de processor belast wordt in putty: z'n piek is zo'n 99,8% dus dat lijkt me duidelijk.

de test heb ik ongeveer 20x uitgeprobeerd aangezien ik ze in een browsertje kan testen dmv refresh. het varieert tussen de 7.6 en 7.8 op de xeon, en tussen de 5.7 en 5.9 op mijn laptop.

[update]
ik heb zover ik kan overzien geoptimaliseerd, zit op mijn laptop nu tussen de 3.72 en 3.79 seconden en op de webserver tussen de 4.44 en 4.47 seconden.

[ Voor 17% gewijzigd door js303 op 16-03-2004 03:12 ]

[Grijze Vos]

Het idee achter multiprocs is dat de ene proces A afhandelt, en de ander proces B.

Mocht proces A in deadlock komen en processor 0 vastzetten, dan kan processor 1 nog altijd doorkachelen, totdat op de een of andere manier die deadlock is opgelost.

[Wirf]

js303 schreef op 16 maart 2004 @ 02:55:
hmmm, ik heb iig performance-winst kunnen boeken door de min en max functies te vervangen door if statements, bijv. if ($outr < $outlo) $outr = $outlo;

vreemd dat zoiets sneller is dan een max()...

Dit is helemaal niet vreemd, je doet immers een functieaanroep, als je de max() functie gebruikt.
Als je een functie aanroept, zal er eerst aardig wat moeten gebeuren voordat lokale variabelen en argumenten goed werken.

Bij gecompileerde talen zoals C en C++ wordt dit vaak weggeoptimaliseerd door het zogenaamde "inlinen" van functies, in plaats van een functieaanroep wordt dan gewoon de (gecompileerde) code van de functie op de plaats van de functieaanroep gezet. PHP is nog niet zo slim.

Maargoed, het gaat wel aardig offtopic inderdaad.

[js303]

Grijze Vos schreef op 16 maart 2004 @ 03:06:
Het idee achter multiprocs is dat de ene proces A afhandelt, en de ander proces B.

Mocht proces A in deadlock komen en processor 0 vastzetten, dan kan processor 1 nog altijd doorkachelen, totdat op de een of andere manier die deadlock is opgelost.

ja klinkt logisch. stond ik even niet bij stil, stom.
1 proces delen is idd beetje lastig kan ik me zo voorstellen.

[js303]

is het in zijn algemeenheid bekend dat er verschillen in performance zijn tussen win32 en *nix versies van php? of moet ik het hier niet in zoeken? is een Pentium_M gewoon super?

[Erik Jan]

Allemaal leuk en aardig, maar check je error_reporting settings. Volgens mij is je script zo traag omdat er allerlei dingen door de PHP engine gecorrigeerd worden. Check onder andere regel 111 - 113 en floats als array keys ($hist) zijn ook een beetje raar.

E_ALL is your friend.

[js303]

valt wel mee hoor. php zeurt-ie alleen om niet-gezette vars en indexen voor de hist[] array, als ik dat 1x zet krijg ik verder geen meldingen. regels 111-113 had ik poosje terug nog in zoverre gecorigeerd dat ik het 2e stuk 1x voorbereken, ipv telkens weer. en de min/max vervangen door if-statements.

als ik een (int) voor de index zet in $hist[ (int) $gst]++ dan wordt-ie alleen maar langzamer.

overigens merk ik dat de functies imagecolorresolve() en imagecolorsforindex(). dus ik heb (onder andere) dit:

code:

$rgb    = imagecolorsforindex($img, $pxl);
$outr   = min($outhi, max(outlo, ($rgb['red'] - $darkest) * $range));
$outg   = min($outhi, max(outlo, ($rgb['green'] - $darkest) * $range));
$outb   = min($outhi, max(outlo, ($rgb['blue'] - $darkest) * $range));

door dit:

code:

$outr   = ( (($pxl >> 16) & 0xFF) - $darkest) * $range;
$outg   = ( (($pxl >> 8) & 0xFF) - $darkest) * $range;
$outb   = ( ($pxl & 0xFF) - $darkest) * $range;

vervangen. en dat 2x. scheelt bij mekaar weer 1 seconde. ik zit nu gemm. op de 2.76 lokaal, dat was eerst 5.8.

@ wirf: dat was een heeeele goeie tip van jou!

[ Voor 84% gewijzigd door js303 op 16-03-2004 03:50 ]

[Erik Jan]

Met de opmerking over regel 111-113 doelde ik erop dat de constante outlo niet bestaat. PHP zet hem wel om, maar om nou 500*400*3 keer afhankelijk te zijn van een soort n00b-protectie. Persoonlijk vind ik dit slecht gedrag van PHP (programmeurs worden lui) waardoor dus spaarzame CPU cycles verloren gaan.

Wat als PHP zo ingesteld staat dat het geen notices displayed in de browser, maar wel in een log-file wegschrijft? Hoe ga jij die 100en verdwenen giegs dan verklaren?

Tevens los je met een simpele (int) ook het probleem van het array niet op, vooralsnog zou ik nog even naar de notices kijken voor het eigenlijke probleem.

[js303]

Erik Jan schreef op 16 maart 2004 @ 04:01:
Met de opmerking over regel 111-113 doelde ik erop dat de constante outlo niet bestaat. PHP zet hem wel om, maar om nou 500*400*3 keer afhankelijk te zijn van een soort n00b-protectie. Persoonlijk vind ik dit slecht gedrag van PHP (programmeurs worden lui) waardoor dus spaarzame CPU cycles verloren gaan.

Wat als PHP zo ingesteld staat dat het geen notices displayed in de browser, maar wel in een log-file wegschrijft? Hoe ga jij die 100en verdwenen giegs dan verklaren?

Tevens los je met een simpele (int) ook het probleem van het array niet op, vooralsnog zou ik nog even naar de notices kijken voor het eigenlijke probleem.

laat mijn display_errors nou wel aanstaan, dus vragen alvorens aan te nemen en vooruit te lopen.

tevens: ik schreef toch al dat ik die regels heb veranderd. ik wist meteen al dat dit een onnodige tijdvreter was maar liet het staan omdat ik er nog aan het tweaken was en stap-voor-stap de onderdeeltjes heb gebouwd. als je het begin vd topic leest snap je waar het over gaat. het was GEEN FINAL maar snel ingeklopte code en het topic ging hier over de verschillen in performances tussen 2 machines en niet over het optimizen van code, hoewel het nu meer een dergelijk topic aan het worden is. ik liep tijdens het eerste testen toevallig tegen de opvallend grote tijdverschillen aan en dus heb ik daarom dit hier gepost.

om gelijk over slecht gedrag van PHP programmeurs te gaan spreken vind ik een beetje raar want deze code was nog helemaal niet productieklaar, en je weet helemaal niet hoe al mijn andere php-code eruit ziet. dus om meteen al met dat soort preken te beginnen, vind ik hier helemaal niet van toepassing. daar zijn genoeg andere topics over te vinden.

[ Voor 9% gewijzigd door js303 op 16-03-2004 04:31 ]

[Grijze Vos]

Persoonlijk vind ik dat je in alle fases van het coden netjes hoort te werken, het achteraf tweak-werk is meer bedoeld als nette functies ombouwen in viezere snellere code, IMHO. Maar ok, daar over doorzeiken is natuurlijk niet echt constructief, niet iedereen werkt op dezelfde manier, en dat is nou ook een van de mooie dingen aan programmeren.

Het enige wat ik me nog kan indenken is dat er iets fout is gegaan bij het compileren van GDlib op die Xeon-machine. Want hij zou toch echt sneller moeten zijn.

Of is misschien een Xeon baggerslecht in dit type operaties? Kben niet zo thuis in de Intel-processoren...

[crisp]

nog een kleine performance-verbetering:

PHP:

for ($y = 0; $y < $imgh; $y++) { }

vervangen door

PHP:

$y = $imgh;
while (--$y) { }

da's wel gerommel in de marge, maar scheelt toch weer iets
Kan je je huidige code eens posten, dan zal ik er nog eens naar kijken vanavond.

algemeen: kijk ook eens naar eventuele verschillen in de GD-versies. De versie PHP is hier denk ik ondergeschikt omdat de meeste tijd toch in de GD-functies zit.

[ Voor 38% gewijzigd door crisp op 16-03-2004 07:50 ]

[djluc]

Kun je niet eens een aantal tijdmetingen binnen je script houden? Dus na belangrijke functie e.d. Dan krijg je veel meer inzicht waar de meeste tijd in gaat zitten, en waar dus het grote verschil wat betreft performance in gaat zitten. Ik verwacht namelijk ook dat het niet in PHP zelf zit.

Maak eventueel een scriptje die een groot aantal iteraties uitvoert, maar verder geen gd functie gebruikt. Dan kun je mooi je performance testen.

[crisp]

De grootste performance bottleneck zit 'm natuurlijk in het 2x uitvragen van de kleur; als je dat de eerste keer al cached in en array scheelt dat al enorm denk ik.
Hier mijn versie (niet getest, enkel gewijzigde gedeelte):

PHP:

    // ==========================================
    // settings
    // ==========================================

    ss_timing_start();

    $outlo            = 0;        // laagste output-grens
    $outhi            = 255;      // hoogste output-grens
    $skiptreshold     = 0.001;    // sla een tint over indien deze heel weinig voorkomt (default = 0.001)

    // ==========================================
    // open het originele plaatje
    // ==========================================

    $img      = imagecreatefromjpeg('test3.jpg');
    $imgw     = imagesx($img);
    $imgh     = imagesy($img);

    // ==========================================
    // maak een histogram van het plaatje
    // ==========================================

    $backup = array();
    $hist = array_fill(0,255,0);

    $y = $imgh;
    while ($y--) {

        $backup[$y] = array();
        $x = $imgw;
        while ($x--) {

            $pxl            = imagecolorat($img, $x, $y);
            $r              = ($pxl >> 16) & 0xFF;
            $g              = ($pxl >> 8) & 0xFF;
            $b              = $pxl & 0xFF;
            $backup[$y][$x] = array($r, $g, $b);
            $gst            = $r * 0.3 + $g * 0.59 + $b * 0.11;
            $hist[(int)$gst]++;

        }

    }

    // ==========================================
    // zoek horizontaal en verticaal bereik uit
    // ==========================================

    $treshold = $skiptreshold * $imgw * $imgh;
    $darkest  = 255;    // donkerste grijstint (we werken naar beneden toe)
    $lightest = 0;      // lichtste grijstint (we werken omhoog)

    $v = 256;
    while ($v--);

        // --------------------------------------
        // zoek bereik van donkerste tot lichtste tint
        // --------------------------------------

        if ($hist[$v] < $treshold) continue;    // indien een grijswaarde ZO weinig voorkomt, skip deze dan
        if ($v < $darkest) $darkest = $v;
        elseif ($v > $lightest) $lightest = $v;

    }

    // ==========================================
    // bereken nieuwe plaatje
    // ==========================================

    $dst    = ImageCreateTrueColor     ($imgw, $imgh);
    $range    = ($outhi - $outlo) / ($lightest - $darkest);

    $y = $imgh;
    while ($y--) {

        $x = $imgw;
        while ($x--) {

            $r = ($backup[$y][$x][0] - $darkest) * $range;
            if ($r < $outlo) $r = $outlo;
            elseif ($r > $outhi) $r = $outhi;

            $g = ($backup[$y][$x][1] - $darkest) * $range;
            if ($g < $outlo) $g = $outlo;
            elseif ($g > $outhi) $g = $outhi;

            $b = ($backup[$y][$x][2] - $darkest) * $range;
            if ($b < $outlo) $b = $outlo;
            elseif ($b > $outhi) $b = $outhi;

            $col     = imagecolorresolve($dst, (int)$r, (int)$g, (int)$b);
            imagesetpixel($dst, $x, $y, $col);

        }
    }

[bigtree]

Is het niet een idee om voor deze specifieke taak een binary te compileren en die vanuit PHP aan te roepen? Is gegarandeerd sneller.

[js303]

die while ipv for scheelt idd ook. truuk die ik zeker vaker ga gebruiken. ik heb nu timers na alle loops en na load en create image geplaatst. results op mijn pc geven aan dat de meeste tijd gaat zitten in de laatste loop, veroorzaakt door imagecolorresolve() en imagesetpixel(). ik heb imagecolorresolve() al vervangen door imagecolorexact() en imagecolorclosest() maar maakt geen donder uit. imagesetpixel(), is daar een alternatief voor?

een vriend van me vroeg zich af of het mogelijk is dat een machine maximaal zoveel % CPU kracht aan een proces mag wijden, zodat bij 20x een dergelijk proces de machine niet helemaal lam ligt. kan dit een oorzaak zijn bij de tragere results op het xeon-moederschip?

je kan het testen op: http://www.workbaby.com/_autocontrast4.php

hier een nettere, dusver optimized versie vd code:

PHP:

<?php

    ini_set("precision", 12);
    ini_set("display_errors", 1);
    error_reporting(E_ALL);

    // ==========================================
    // init vars
    // ==========================================

    $outlo          = 0;            // laagste output-grens
    $outhi          = 255;          // hoogste output-grens
    $skiptreshold   = 0.001;        // sla tint over indien deze heel weinig voorkomt (default = 0.001)
    $file           = "test4.jpg";  // plaatje te bewerken

    $timer          = array();              // declareer vars om warnings te voorkomen (dank aan de tweakers)
    $hist           = array_fill(0,256,0);  // vul met lege waardes (thanks crisp)

    // ==========================================
    // Timing functies voor script exection time
    // ==========================================

    function ss_timing_start ($name = 'default') {
        global $ss_timing_start_times;
        $ss_timing_start_times[$name] = explode(' ', microtime());
    }

    function ss_timing_stop ($name = 'default') {
        global $ss_timing_stop_times;
        $ss_timing_stop_times[$name] = explode(' ', microtime());
    }

    function ss_timing_current ($name = 'default') {
        global $ss_timing_start_times, $ss_timing_stop_times;
        if (!isset($ss_timing_start_times[$name])) {
            return 0;
        }
        if (!isset($ss_timing_stop_times[$name])) {
            $stop_time = explode(' ', microtime());
        }
        else {
            $stop_time = $ss_timing_stop_times[$name];
        }
        // do the big numbers first so the small ones arent lost
        $current = $stop_time[1] - $ss_timing_start_times[$name][1];
        $current += $stop_time[0] - $ss_timing_start_times[$name][0];
        return $current;
    }

    ss_timing_start();

    // ==========================================
    // open het originele plaatje
    // ==========================================

    $img    = imagecreatefromjpeg($file);
    $imgw   = imagesx($img);
    $imgh   = imagesy($img);

    $timer[0] = ss_timing_current();

    // ==========================================
    // maak een histogram van het plaatje
    // ==========================================

    $y = $imgh;
    while ($y--) {
        $x = $imgw;
        while ($x--) {
            $pxl    = imagecolorat($img, $x, $y);   // colorindex / rgb-waarde van pixel(x,y)
            $gst    = (($pxl >> 16) & 0xFF) * 0.3
                    + (($pxl >> 8) & 0xFF) * 0.59
                    + ($pxl & 0xFF) * 0.11;         // converteer naar grijswaarde

            $hist[(int)$gst]++;                         // tel aantal van deze grijswaardes
        }
    }

    $timer[1] = ss_timing_current();

    // ==========================================
    // zoek horizontaal en verticaal bereik uit
    // ==========================================

    $least      = 255;              // minimale en maximale 8bit waarden
    $most       = 0;
    $totpixels  = $imgw * $imgh;    // totaal aantal pixels in plaatje
    $darkest    = 255;              // donkerste grijstint (we werken naar beneden toe)
    $lightest   = 0;                // lichtste grijstint (we werken omhoog)

    $i = 256;
    while ($i--) {
        // --------------------------------------
        // zoek bereik van aantal pixels uit
        // dus de tint die het minst voorkomt
        // en de tint die het meest voorkomt
        // --------------------------------------

        $least  = min($least, $hist[$i]);
        $most   = max($most, $hist[$i]);

        // --------------------------------------
        // zoek bereik van donkerste tot lichtste tint
        // --------------------------------------

        if ($hist[$i] / $totpixels < $skiptreshold) continue;   // indien een tint te weinig voorkomt, skip deze dan
        $darkest    = min($darkest, $i);
        $lightest   = max($lightest, $i);
    }

    $scale = ($most-$least) / 100;

    $timer[2] = ss_timing_current();

    // ==========================================
    // bereken nieuwe plaatje
    // ==========================================

    $dst    = ImageCreateTrueColor  ($imgw, $imgh);
    $fg     = imagecolorallocate($dst, 255, 200, 0);
    $range  = ($outhi - $outlo) / ($lightest - $darkest);   // stretch het contrast op tot de outer limits 0 en 255

    $timer[3] = ss_timing_current();

    $y = $imgh;
    while ($y--) {
        $x = $imgw;
        while ($x--) {
            $pxl    = imagecolorat($img, $x, $y);   // colorindex / rgb-waarde van pixel(x,y)

            $outr   = ( (($pxl >> 16) & 0xFF) - $darkest) * $range;
            $outg   = ( (($pxl >> 8) & 0xFF) - $darkest) * $range;
            $outb   = ( ($pxl & 0xFF) - $darkest) * $range;

            if ($outr < $outlo) $outr = $outlo;
            if ($outg < $outlo) $outg = $outlo;
            if ($outb < $outlo) $outb = $outlo;

            if ($outr > $outhi) $outr = $outhi;
            if ($outg > $outhi) $outg = $outhi;
            if ($outb > $outhi) $outb = $outhi;

            $col    = imagecolorresolve($dst, (int)$outr, (int)$outg, (int)$outb);

            imagesetpixel($dst, $x, $y, $col);
        }
    }

    $timer[4] = ss_timing_current();

    imagestring     ($dst, 3, 2, $imgh - 65, "0 - start", $fg);
    imagestring     ($dst, 3, 2, $imgh - 55, $timer[0] . " - load img", $fg);
    imagestring     ($dst, 3, 2, $imgh - 45, $timer[1] . " - histogram", $fg);
    imagestring     ($dst, 3, 2, $imgh - 35, $timer[2] . " - bereik", $fg);
    imagestring     ($dst, 3, 2, $imgh - 25, $timer[3] . " - create img", $fg);
    imagestring     ($dst, 3, 2, $imgh - 15, $timer[4] . " - contrast", $fg);

    header          ("Content-type: image/jpeg");
    imagejpeg       ($dst, false, 80);
    imagedestroy    ($dst);

    // ==========================================
    // sluit plaatje
    // ==========================================

    imagedestroy    ($img);
    exit            ();

?>

[ Voor 10% gewijzigd door js303 op 16-03-2004 14:07 ]

[js303]

@ crisp:

heb je code bekeken, en zag array_fill() had ik ook moeten gebruiken natuurlijk (hoewel het nu niks aan performance scheelt).

echter het wegschrijven naar en ophalen van de $backup array maakt het langzamer dan 2x het gebruik van imagecolorat(). waar ik eerst op de 2.45 zat kom ik nu op de 2.83 uit! wellicht komt dit omdat het zo'n grote array wordt.

@ bigtree: volgens mij is het niet mogelijk om php te compileren heb ik ooit gelezen. dus zou het in c++ oid moeten. en dat ken ik nie.

[ Voor 17% gewijzigd door js303 op 16-03-2004 14:24 ]

[Banpei]

Om even op de orginele vraag terug te komen:
1. Welke webserver gebruik je onder XP?
2. Draait PHP als dll of als exe op de mobile?
3. Hoe staat je apache op de Redhat bak ingesteld?
4. Wat is het max. geheugen dat beide mogen gebruiken per script?

Dit ivm dat wij hier op mijn werk een hogere performance halen met een testserver dan op de productie, terwijl de testserver 2,5 keer zo langzaam is en 2 keer zo weinig geheugen heeft. Dit zit em voornamelijk in dat de testserver meer geheugen en cpu mag gebruiken dan op de productie server. Dit om te voorkomen dat de productie alle resources naar een proces gaat gooien en dus een hogere bereikbaarheid heeft.

[js303]

Banpei schreef op 16 maart 2004 @ 14:27:
Om even op de orginele vraag terug te komen:
1. Welke webserver gebruik je onder XP?
2. Draait PHP als dll of als exe op de mobile?
3. Hoe staat je apache op de Redhat bak ingesteld?
4. Wat is het max. geheugen dat beide mogen gebruiken per script?

Dit ivm dat wij hier op mijn werk een hogere performance halen met een testserver dan op de productie, terwijl de testserver 2,5 keer zo langzaam is en 2 keer zo weinig geheugen heeft. Dit zit em voornamelijk in dat de testserver meer geheugen en cpu mag gebruiken dan op de productie server. Dit om te voorkomen dat de productie alle resources naar een proces gaat gooien en dus een hogere bereikbaarheid heeft.

1. Apache 1.3.24 op XP laptop, Apache 1.3.27 op Red-Hat/Linux webserver
2. draait als module van Apache, dus dan is het een dll als ik het goed heb.
3. weet ik niet precies wat je bedoelt? waar moet ik naar kijken?
4. memory limit: als ik met phpinfo() kijk zie ik dat m'n XP laptop geen memory_limit laat zien, dus zou je denken dat-ie uitstaat oid. dus ik kijk in php.ini, daar staat-ie op 8mb. op de webserver staat-ie iig op 32mb. is dit een feature die niet op de windows versie van php ondersteund wordt (kon niks op php.net vinden)?

[crisp]

er valt inderdaad niet zo heel erg veel meer aan te tweaken qua snelheid; het cachen van de kleuren is inderdaad meer overhead dan het opnieuw opvragen.
De meeste tijd zit inderdaad in de laatste stap, en de berekeningen vergen daarvan een groot deel, maar daar kom je niet onderuit. Al met al is het ongeveer 50/50 qua image-functie processing en echte berekeningen.

[Wirf]

nog een allerlaatste optimalisatie, die het een heel stuk sneller maakt (duurt 0.2 sec. op mijn computer en die is langzamer dan die P-mobile en Xeon)

PHP:

<?
$file="test4.jpg";
exec( "convert $file -normalize output.jpg");
print("[img]output.jpg>");
?[/img]

[ Voor 53% gewijzigd door Wirf op 17-03-2004 01:51 ]

[js303]

Wirf schreef op 17 maart 2004 @ 01:49:
nog een allerlaatste optimalisatie, die het een heel stuk sneller maakt (duurt 0.2 sec. op mijn computer en die is langzamer dan die P-mobile en Xeon)

PHP:

<?
$file="test4.jpg";
exec( "convert $file -normalize output.jpg");
print("[img]output.jpg>");
?[/img]

hahah. ik kan geen gebruikmaken van imagemagick, dus moet ik het zo doen.
maar je punt is duidelijk: waarom al die moeite doen als het ook makkelijk kan.