[coredev]

Ursprungligen postat av ConnyWesth

Det är ytterst sällan som prestandaoptimering är första fokus i användarinteraktiva applikationer. Mer än 90-99 procent av datorns tid står den och väntar på att användaren ska utföra något, så att optimera användargränssnitt för hastighet är i normalfallet mindre viktigt (lägre prioriterat)...

Nope.

Det stämmer säkert när det gäller vanliga windowsapplikationer, men detta är en webbapplikation och där har du helt andra krav. Tar något mer än 2 sekunder så kan du räkna med att användaren laddar om sidan ELLER tröttnar - båda är rätt dåliga scenarion. Du riskerar dessutom att bli straffade i SERP:en om din webbplats snurrar långsamt. Utvecklar du webbapplikationer skall du ha ett högt fokus på just prestanda.

[tartareandesire]

Ursprungligen postat av coredev

Nope.

Det stämmer säkert när det gäller vanliga windowsapplikationer, men detta är en webbapplikation och där har du helt andra krav. Tar något mer än 2 sekunder så kan du räkna med att användaren laddar om sidan ELLER tröttnar - båda är rätt dåliga scenarion. Du riskerar dessutom att bli straffade i SERP:en om din webbplats snurrar långsamt. Utvecklar du webbapplikationer skall du ha ett högt fokus på just prestanda.

Exakt. Driften är dessutom också en kostnad man måste räkna med + att miljötänk även bör finnas med inom webbutveckling. Det här handlar ju inte alls om optimering i efterhand heller vilket gör att det inte tar någon extra tid om man har koll på vad man gör.

[dAEk]

Istället för att argumentera fram och tillbaka - kan ni inte göra mätningar från ett av era projekt och lägga upp resultaten här? CPU time, pages/sec och kanske något till mätvärde som kan vara intressant för att mäta skillnaden.

Eftersom jag inte kan PHP blir det en vild gissning och det är att skillnaden förmodligen är försvinnande liten.

[tartareandesire]

Ursprungligen postat av dAEk

Istället för att argumentera fram och tillbaka - kan ni inte göra mätningar från ett av era projekt och lägga upp resultaten här? CPU time, pages/sec och kanske något till mätvärde som kan vara intressant för att mäta skillnaden.

Eftersom jag inte kan PHP blir det en vild gissning och det är att skillnaden förmodligen är försvinnande liten.

Skillnaden är i de flesta fall försvinnande liten, ja, men varje optimeringsmöjlighet är för trafikintensiva webbplatser mycket viktig. Många bäckar små. Detta är som sagt var också en så pass simpel optimeringsmöjlighet att det borde gå per automatik.

Att det är en skillnad mellan normalvarianten och _once är självförklarande av funktionaliteten i sig. Det finns en hel del skrivet på nätet redan med diverse tester. Den faktiska skillnaden varierar ju dock en del från en webbplats till en annan i likhet med de flesta andra optimeringar man kan göra.

[SimonP]

Appropå prestanda, i de flesta fall är ju OOP att föredra, men i de fall där man skall processa mkt data kan OOP ge en märkbar prestandaförsämring. För några år sedan gjorde jag tester mellan vanlig kod och OOP kod. I koden nedan krypteras en 1k-sträng 1k gånger, dvs totalt 1 megabyte data. OOP-varianten ger en enorm prestandaförsämring, flera hundra procent, testade även nu på en obelastad server med följande resultat:

Non OOP Result: 1.6096091270447 seconds
OOP Result: 4.6408619880676 seconds

<?php

// Create 1k string
$initString="";
while (strlen($initString)<1024) $initString .="abcdef0123456789";

/*
---------------------------------------------------
 Non-OOP test
---------------------------------------------------
*/
$time_start = microtime(true);
for ($i=0; $i<1024; $i++)
{
	Non_OOP_test($initString,false);
}
$time_end = microtime(true);
$time = ($time_end - $time_start);
echo "<pre>Non OOP Result: $time seconds\n";

// Verification
$encrypted	= Non_OOP_test($initString,true);
$decrypted	= Non_OOP_test($encrypted,true);
echo "Encrypted: $encrypted\n";
echo "Decrypted: $decrypted\n</pre>";

/*
---------------------------------------------------
 OOP test
---------------------------------------------------
*/
$time_start = microtime(true);
for ($i=0; $i<1024; $i++)
{
	OOP_test($initString,false);
}
$time_end = microtime(true);
$time = ($time_end - $time_start);
echo "<pre>OOP Result: $time seconds\n";

// Verification
$encrypted	= OOP_test($initString,true);
$decrypted	= OOP_test($encrypted,true);
echo "Encrypted: $encrypted\n";
echo "Decrypted: $decrypted\n</pre>";



function OOP_test($instr, $return)
{
	$arc4 = new ARC4();
	$arc4->init("pAsSwOrD");
	$arc4->process($instr,1024);
	if ($return) return $instr;
}


function Non_OOP_test($instr, $return)
{
	global $x, $y, $state, $statebackup;
	$x = $y = 0;
	$state = array();
	$statebackup =array();
	arc4_init("pAsSwOrD");
	arc4_process($instr,1024);
	if ($return) return $instr;
}

//-------------------------------------------------------------------------------
// ARC4 Encryption class in PHP
//--------------------------------------------------------------------------------
class ARC4
{
   private $state = array();
   private $statebackup = array ();
   private $x = 0;
   private $y = 0;

   function init($key)   // init key schedule
   {
      $len= strlen($key);
      for ($this->x = 0; $this->x < 256; $this->x++) $this->state[$this->x] = $this->x;

      $this->y = 0;
      for ($this->x = 0; $this->x < 256; $this->x++)
      {
         $this->y = ($this->y + $this->state[$this->x] + ord($key[$this->x % $len])) % 256;
         $temp = $this->state[$this->x];
         $this->state[$this->x] = $this->state[$this->y];
         $this->state[$this->y] = $temp;
      }
        
      // Skip the first 256 bytes to avoid some weakness
      $temp="";
      for ($this->x = 0; $this->x < 256; $this->x++) $temp[$this->x]=chr($this->x);
      $this->process($temp,256); 

      $this->x = $this->y = 0;
      $this->statebackup=$this->state;
    }

   function process(&$instr, $len)  // encrypt/decrypt raw ascii
   {
      for ($c= 0; $c < $len; $c++)
      {
         $this->x = ($this->x + 1) % 256;
         $this->y = ($this->y + $this->state[$this->x]) % 256;
         $temp = $this->state[$this->x];
         $this->state[$this->x] = $this->state[$this->y];
         $this->state[$this->y] = $temp;
         $instr[$c] = chr(ord($instr[$c]) ^ $this->state[($this->state[$this->x] + $this->state[$this->y]) % 256]);
      }
   }
}    
//--------------------------------------------------------------------------------------------------

	
function arc4_init($key)   // init key schedule
{
	global $x, $y, $state, $statebackup;
	
	$len= strlen($key);
   for ($x = 0; $x < 256; $x++) $state[$x] = $x;
   $y = 0;
   for ($x = 0; $x < 256; $x++)
   {
      $y = ($y + $state[$x] + ord($key[$x % $len])) % 256;
      $temp = $state[$x];
      $state[$x] = $state[$y];
      $state[$y] = $temp;
   }
     
   // Skip the first 256 bytes to avoid some weakness
   $temp="";
   for ($x = 0; $x < 256; $x++) $temp[$x]=chr($x);
   arc4_process($temp,256); 

   $x = $y = 0;
   $statebackup=$state;
}


function arc4_process(&$instr, $len)  // encrypt/decrypt raw ascii
{
	global $x,$y,$state;
		
   for ($c= 0; $c < $len; $c++)
   {
      $x = ($x + 1) % 256;
      $y = ($y + $state[$x]) % 256;
      $temp = $state[$x];
      $state[$x] = $state[$y];
      $state[$y] = $temp;
      $instr[$c] = chr(ord($instr[$c]) ^ $state[($state[$x] + $state[$y]) % 256]);
   }
}

?>

[Conny Westh]

Jag testkörde SimonPs kod (på en betydligt långsammare maskin) och fick följande resultat:

Non OOP Result: 2.6286079883575 seconds
OOP Result: 5.3388919830322 seconds

Jag noterar att Simons Ratio (ImperativeTime/OOPtime) blev 2,88 medan min blev 2,03, det har m a o ganska stor betydelse vilken maskin man kör på.

Sen har det alltid varit så att OOP körningar tar något längre tid eftersom det är mer att göra för systemet. Det är inte av prestandaskäl man väljer OOP i stället för imperativa språk, det är för att kunna hantera komplexitet på ett bättre sätt och minska risken för buggar, återanvändbarhet av tidigare kod, samt därmed kortare utvecklingstid. Maskiner blir ständigt snabbare så hastigheten är inte det avgörande i de flesta fall. PHP ger i sig prestandaförluster i och med att det dessutom är interpreterande och inte kompilerande. Är hastigheten en kritisk faktor så väljer man ett annat språk.

[SimonP]

Ursprungligen postat av ConnyWesth

Sen har det alltid varit så att OOP körningar tar något längre tid eftersom det är mer att göra för systemet. Det är inte av prestandaskäl man väljer OOP i stället för imperativa språk, det är för att kunna hantera komplexitet på ett bättre sätt och minska risken för buggar, återanvändbarhet av tidigare kod, samt därmed kortare utvecklingstid. Maskiner blir ständigt snabbare så hastigheten är inte det avgörande i de flesta fall. PHP ger i sig prestandaförluster i och med att det dessutom är interpreterande och inte kompilerande. Är hastigheten en kritisk faktor så väljer man ett annat språk.

Jag ville mest belysa prestandaproblem som OOP ger i vissa undantag. Jag har upplevt samma sak i kompilerande språk, t.ex C/C++, dvs. att OOP ger en försämring i prestanda vid intensiva anrop, inte lika mkt som PHP men ändå märkbar.

[danjel]

Ursprungligen postat av ConnyWesth

.... PHP ger i sig prestandaförluster i och med att det dessutom är interpreterande och inte kompilerande. Är hastigheten en kritisk faktor så väljer man ett annat språk.

Nja, det stämmer inte. De flesta trafikintensiva använder någon slags bytecode cache för prestanda.


Vad gäller detta test, intressant vore se vilken skillnad det blir om man använder statisk metoder istället för instansiering. Förmodligen lite mindre minnesutnyttjande, vilket ju blir lite mer "rättvist" eftersom oop gör lite mer än funktionella koden om den instansierar

[Conny Westh]

Ursprungligen postat av danjel

Nja, det stämmer inte. De flesta trafikintensiva använder någon slags bytecode cache för prestanda.


Vad gäller detta test, intressant vore se vilken skillnad det blir om man använder statisk metoder istället för instansiering. Förmodligen lite mindre minnesutnyttjande, vilket ju blir lite mer "rättvist" eftersom oop gör lite mer än funktionella koden om den instansierar

Nej, bytecode cache (som ju sker i runtime eller är det JIT Compilation du menar) kan aldrig mäta sig med kompilerad kod (som ju förkompilerar och optimerar koden).

Stark typning kan i många programspråk ge 50-100 gånger prestandaförbättring även i en interpreterande eller semikompilerad miljö.

Dock helt riktigt att statiska metoder ger betydande prestandaförbättring i OOP-sammanhang jämfört med instansiering, men det beror på vilket problem man ska lösa om man kan använda det eller inte.

[danjel]

Med bytecode caches så kompileras och parsas koden endast vid första request. Så den overhead som JIT kompilering ger per default i PHP kan alltså undvikas.

Jag invände mot att du sa : om hastighet är en kritisk faktor så väljer man ett annat språk. Om man gör extremt stora beräkningar m.m i kod så är det klokt att inte använda php, t.ex motsvarande detta performance test i denna tråd. Där skulle asp.net eller cgi/c++ "vinna".
Det jag menar är att generellt väljer man inte bort php pga sämre prestanda i webblösningar.