[znap]

Frågan låter som att den har ett självklart svar men jag börjar undra...

Jag jobbar med en stor wordpress-installation (~500000 poster/attachments). Vi har höga krav på prestanda och tillgänglighet. När man laddar hem och testar plugins som finns där ute så blir man tyvärr varse att kodkvaliteten är mycket låg. Utvecklarna tar sällan i beaktning att man kan ha många poster i en databas, dvs att man tex inte kan läsa in alla poster som finns i databasen i en array. Man får lägga mycket tid på att felsöka och fixa den typen av saker.

Ett vanligt fel som vi kan se är att utvecklarna stänger av felrapportering och koder allmänt slarvigt. Tex att man anropar variabler utan att vara säker på om variablerna existerar. I produktionsmiljön har vi varit tvungna att supressa vissa felmeddelanden, annars skulle det öht inte gå vägen.

Min fråga är då om man helt enkelt ska strunta i att det triggas mindre allvarliga error när koden körs? Att det prestandamässigt skulle vara bättre att dölja felmeddelandet istället för att i koden först kolla om en variabel är satt innan man kollar vad variabeln innehåller. Koden kan tex se ut på följande sätt

PHP-kod:

  if($_GET['var'] == 12) // $_GET['var'] existerar inte alltid men ändå kör man if-satsen varje gång

  if($obj->var == 12) // Objektet har ingen property vid namn "var" men ändå kollar man värdet 


Jag arbetade tidigare med ett CMS i java, så jag blir något förbryllad när jag ser kod där man anropar variabler som aldrig blivit definerade på det här sättet

[intedinmamma]

PHP-kod:

<?php
$array = array();

$start = microtime();

for($i = 0; $i < 10000; $i++) {
    if(isset($array['item'])) {
        echo $array['item'];
    }
}

$end = microtime() - $start;
echo "Array med isset(): $end\n";
$result_with = $end;

$start = microtime();

for($i = 0; $i < 10000; $i++) {
    echo $array['item'];
}

$end = microtime() - $start;
echo "Array utan isset(): $end\n";
echo "vs: ".($end / $result_with)." gångers skillnad\n";

$object = (object) array();
$start = microtime();

for($i = 0; $i < 10000; $i++) {
    if(isset($object->item))
        echo $object->item;
}

$end = microtime() - $start;
$result_with = $end;
echo "Objekt med isset(): $end\n";

$object = (object) array();
$start = microtime();

for($i = 0; $i < 10000; $i++) {
    echo $object->item;
}

$end = microtime() - $start;
echo "Objekt utan isset(): $end\n";
echo "vs: ".($end / $result_with)." gångers skillnad\n";

Med den koden varierar skillnaden i prestanda mellan 3 och 10 gånger, till fördel för exemplena med isset().

Fast frågan är hur mycket skillnad det gör i längden, tiden som går åt är försumbar i förhållande till t ex tiden det tar att hämta information från databasen.

[znap]

good point!

Ändå jäkligt frustrerande att jobba med den typen av fel. I testmiljön har vi all debug påslagen då vi inte accepterar slarv i vår egenproducerade kod men då blir det helt plötsligt svårt att använda andras plugin just pga detta.

Men som du säger, det ligger helt klart längst ner på priolistan över möjliga kodoptimeringar.

[emilv]

Den stora frågan är: vill du verkligen använda moduler med så låg kodkvalitet?

Att dölja felet med @ är förresten också en dyr operation.

[Jake.Nu]

Om du vågar

script.php

PHP-kod:

<?php
if ($obj->id > 0) {}
$obj = new stdClass();
if ($obj->id > 0) {}
if ($array["id"] < 0) {}
if ($id != 0) {}
?>

fix_file.php

PHP-kod:

<?php
function fix_file($filename) {
    $index = array();
    $props = array();
    $varib = array();
    
    $data = file_get_contents($filename);
    
    ob_start();
    eval(str_replace("<?php", "", $data));
    $rows = explode("\n", ob_get_clean());
    foreach ($rows as $row) {
        if (empty($row)) {
            continue;
        }
        if (preg_match('/Undefined index:\040+(.+)\040+in.+on line\040([0-9]+)/', $row, $match)) {
            $index[$match[2] - 1][] = $match[1];
            continue;
        }
        if (preg_match('/Undefined property:\040+.+::\$(.+)\040+in.+on line\040([0-9]+)/', $row, $match)) {
            $props[$match[2] - 1][] = $match[1];
            continue;
        }
        if (preg_match('/Undefined variable:\040+(.+)\040+in.+on line\040([0-9]+)/', $row, $match)) {
            $varib[$match[2] - 1][] = $match[1];
            continue;
        }
    }
    $rows = explode("\n", $data);
    foreach ($index as $idx => $keys) {
        foreach ($keys as $index_name) {
            if (preg_match('/\$.+\[[\"|\']' . $index_name . '[\"|\']\]/', $rows[$idx], $match)) {
                $rows[$idx] = str_replace($match[0], 'isset(' . $match[0] . ') && ' . $match[0], $rows[$idx]);
                continue;
            }
        }
    }
    foreach ($props as $idx => $keys) {
        foreach ($keys as $prop_name) {
            if (preg_match('/\$.+->' . $prop_name . '/', $rows[$idx], $match)) {
                $rows[$idx] = str_replace($match[0], 'isset(' . $match[0] . ') && ' . $match[0], $rows[$idx]);
                continue;
            }
        }
    }
    foreach ($varib as $idx => $keys) {
        foreach ($keys as $varib_name) {
            if (preg_match('/\$' . $varib_name . '/', $rows[$idx], $match)) {
                $rows[$idx] = str_replace($match[0], 'isset(' . $match[0] . ') && ' . $match[0], $rows[$idx]);
                continue;
            }
        }
    }
    file_put_contents($filename, implode("\n", $rows));
}

error_reporting(E_ALL);
ini_set("display_errors", 1);
ini_set("html_errors", 0);

// fixar bara en fil, gör något själv!
fix_file("./script.php");
?>

[znap]

@intedinmamma
Här är en kul och intressant film inom ämnet http://ontwik.com/php/php-performanc...asmus-lerdorf/ . När Rasmus profilerar en request mot en grundinstallation av wordpress så finner han att endast 10% av exekveringstiden går till kommunikation med databasen, något som han säger är ett varningstecken. Allt han behövde göra för att optimera sin installation avsevärt var att ta bort två widgets från sidebaren har jag för mig.

@emilv
Det är en avvägning man hela tiden måste göra. Vi har faktiskt en utvärderingsmall som man stödjer sig mot i bedömningen om ett plugin kan användas.

@Jake.Nu
Någon form av automatisering för att justera den här typen av fel vore en väg att gå. Det blir dock något mer komplext än att bara köra skriptet då mycket av funktionaliteten läggs i filter och actions. Då måste skriptet klara av den biten också.

Vi använder ett väldigt bra IDE som direkt hittar en mängd fel av det här slaget. Den klarar dock inte av att man typecastar en array till ett objekt då den är omedveten om datakällan, inte heller extract_args som ofta används i wp. Därför blir det vanligtvis en varningsindikering på varenda rad i ett helt plugin

[Jake.Nu]

Ursprungligen postat av znap

@Jake.Nu
Någon form av automatisering för att justera den här typen av fel vore en väg att gå. Det blir dock något mer komplext än att bara köra skriptet då mycket av funktionaliteten läggs i filter och actions. Då måste skriptet klara av den biten också.

"actions" och "filter".. vad är det du pratar om? Kan du ge ett exempel?

[znap]

Det är wordpress-specifika events.

http://codex.wordpress.org/Plugin_API/Action_Reference

http://codex.wordpress.org/Plugin_API/Filter_Reference

[Jake.Nu]

Ursprungligen postat av znap

Det är wordpress-specifika events.

http://codex.wordpress.org/Plugin_API/Action_Reference

http://codex.wordpress.org/Plugin_API/Filter_Reference

Aha, jag sysslar inte med Wordpress själv så det förklarar saken..