« 1 2 3 4 »
Autor Zpráva
Oxidián
Profil *
Mám funkci, která mi ale nefunguje správně. Potřebuju najít která ze tří hodnot je největší a která nejmenší. Je na to v php nějaká funkce nebo musím vytvořit vlastní?

Class Converter{
  private $min;
  private $max;
  private function getMinMax($R, $G, $B)
  {
      if ($R < $G )
      {
          if ($R < $B )
              {
            $min = $R;
              if ( $G > $B )
                  $max = $G;
              else 
                  $max = $B;
              }
          else 
              {
              $min = $B;
              if ( $G > $B )
                  $max = $G;
              else 
                  $max = $B;
              }
     }
      else
          if ( $G < $B )
              {
              $min = $G;
              $max = $B;
              }
          else 
              {
              $min = $B;
              $max = $G;
              }
  $this->min=$min;
  $this->max=$max;
  }
juriad
Profil
Je na to funkce min a max. Obě dokonce umožňují zadat libovolný počet argumentů. Mimochodem, metoda getXYZ má podle názvu vracet hodnotu, nikoli ukládat do nějaké instanční proměnné. Toto opravdu není princip použití OOP.
getMinMax($R, $G, $B) {
return array(min($R, $G, $B), max($R, $G, $B));
}

list($min, $max) = getMinMax(1, 2, 3);
Ale samozřejmě, po tomto zjednodušení ta funkce postrádá smysl.
1Pupik1989
Profil
Nebo
if($G < $R){
  $temp = $R; $R = $G; $G = $temp;  
}

if($B < $R){
  $temp = $B; $B = $R; $R = $temp;  
}

if($B < $G){
  $temp = $B; $B = $G; $G = $temp;
}

Doufám, že v tom nemám hrubku.
Oxidián
Profil *
(Pozn. pokračování předchozího vlákna o funkci, která hledá minimální a maximální hodnotu v objektu rgb).

Hledal jsem nejrychlejší způsob z hlediska počtu kroků. Zkusil jsem udělat si tabulku a logicky to vyhodnotit. Je to podobné jako u binární tabulky, akorát že tam jsou jen tři "bity" (místo bitů jsem dosadil minima a maxima, tedy 0 nebo 255). Takže nejdříve porovnám RxG a pak GxB.
Otestoval jsem všech osum situací podle tabulky a funguje to:

  private function setMinMax($R, $G, $B)
  {
      if ($R <= $G )
      {
        if ($R <= $B )
        {
        $this->min=$R;
        // RED min. established, detect green-blue max
        if ($G >= $B )
         $this->max=$G;
        else
         $this->max=$B;
      }
      else
        {
        $this->min=$G;
        // GREEN min. established, detect green-blue max
        if ($G >= $B )
         $this->max=$G;
        else
         $this->max=$B;
      }
    }
      else
      {
        if ($R >= $B )
        {
        $this->max=$R;
        // RED max. established, detect green-blue min
        if ($G <= $B )
         $this->min=$G;
        else
         $this->min=$B;
      }
      else
        {
        $this->max=$G;
        // RED max. established, detect green-blue min
        if ($G <= $B )
         $this->min=$G;
        else
         $this->min=$B;
      }
    }
  }
1Pupik1989
Profil
Zase ale na čas zpracování vyhraji. Pokud platí, že podmínka je stále pomalejší, než čtení a zápis. Na délku kódu vyhraje zase juriad. Ještě by šlo vytvořit pole z hodnot a použít array_sort.
Radek9
Profil
U takhle primitivní operace bych opravdu nehrál na mikrosekundy a použil juriadovo řešení. Ten rozdíl ve výkonu je zanedbatelný a mnohem lépe se to čte.
Oxidián
Profil *
1Pupik1989:
Fakt jo? Tak to slyším poprvé. Ale třeba v jiném programovacím jazyce by mohla ta podmínka být rychlejší (např. C++). Nebo se pletu?


Radek9:
Ale když zpracováváš velké množství pixelů tak by to třeba mohlo hrát roli. Třeba proč sestavovat pole kvůli každému pixelu jak má juriad?


1Pupik1989:
Jo a mě nevadí, že kód je delší, spíš myslím, že podstatný je čas za který se operace provede. Dejme tomu, že bych se rozhodl udělat s obrázkem 800pxx600px nějaké grafické operace tak to může být poznat si myslím.
1Pupik1989
Profil
$arr = sort(Array($R,$G,$B));

Je ještě kratší. Milisekundy nemá cenu honit, pokud ta operace neprobíhá 100000x. Ve výsledku ale spoustu optimalizací je znát. Takže je otázka jak často se to používá? Proč by to nemělo být rychlejší, když může?
Oxidián
Profil *
Zkoušel jsem upravit jeden script. Malý obrázek png 225px × 300px se schématem. Script používal call_user_func nevím proč, vyřadil jsem to. Pak tam byla třída class Pixel, která se vytváří při načtení každého jednoho pixelu + znova se načítá ve funkci addNoise a tam se taky celý objekt vrací. Původní časy pro zpracování požadavku na efekt addNoise, které jsem naměřil ještě po vyřazení tohoto objektu:
2.34029603004
2.3569829464
2.43400192261
2.36442899704
2.36072778702
2.51370501518
2.61095118523
2.60563206673
sekund.
Nahradil jsem to tedy obyčejným polem na které odkazuju a čas je okolo
1.47858119011-1.53328895569
Tak to je setsakramentsky velký rozdíl. Teď si vemte že bych zpracovával 4x větší obrázek nebo k tomu chtěl přidat další efekty...

Jediný problém který při tomto měření zůstal je ten, že se mi to nepovedlo rozchodit tak jak chodil ten program před mojí úpravou :-)
Nemyslím si, ale že by to mohlo mít vliv. Kdyby se tu někdo někdo z vás na to podíval a zkusil najít chybu, tak by se to snad dalo ověřit s jistotou. Ono to pracuje v podstatně na podobném principu, protože to vracelo pole místo odkazu.

Původní funkce
public function addNoise($pixel, $factor)
Obsahovala první argument $pixel jako objekt.

Pro spuštění staré verze je třeba nastavit konstantu
define("SUPERFAST", false);
SUPERFAST určuje části starého kódu které jsem nahradil za nový.
Původní verze přidává "šum" do obrázku. Nová verze hodnoty nemění a já na to ne a ne přijít.

Image_PixelOperations_class.php
http://paste.ofcode.org/E3tdx9uEPJ5HjW5AZ332Gq
index:
http://paste.ofcode.org/5KJXs7rXW4evhch2EXu8JG


Tak jsem to opravil. Neuložil jsem tu změněnou barvu do správné proměnné. Takže potvrzuji, že teď po úpravě je to rychlejší min. o jednu vteřinu. Vyzkoušejte sami:

http://paste.ofcode.org/BJmwNyExYCQ3hENLS8k6Xq

A teď si představte že bych do toho přimontoval funkce na převod které vracejí pole. Tak to by nebylo zrovna nejrychlejší. I když sestavení pole bude o něco rychlejší než sestavení objektu, zase by ty pole tam byly min. dvě tak to nevidím jako efektivní řešení.
Joker
Profil
1Pupik1989:
Milisekundy nemá cenu honit, pokud ta operace neprobíhá 100000x.
Jestli to dělá pro každý pixel obrázku, může se to dělat i víckrát.

Oxidián:
když zpracováváš velké množství pixelů tak by to třeba mohlo hrát roli.
Já si místo „třeba“ a „mohlo“ raději udělám benchmark ;-)

Takže, milion cyklů, v jednom cyklu se setřídily tři náhodná čísla 0-255 a minimum a maximum uložily do proměnných.
(pro jeden test měly všechny funkce předgenerovanou stejnou sekvenci náhodných čísel.)

Takže, to řešení s nastavováním atributů třídy v mém testu vychází kolem 1,1 sekundy na milion cyklů.
juriadovo řešení vychází kolem 1,7s, takže je pomalejší.

Ještě jsem zkoušel primitivní:
function getMinMax($R, $G, $B) {
  $min = ($B < $G) ? (($R < $B) ? $R : $B) : $G;
  $max = ($B > $G) ? (($R > $B) ? $R : $B) : $G;
  return array($min, $max);
}

jako srovnání, jestli se ušetří použitím atributů oproti vracení hodnoty. Pokud oba kódy byly metody jednoho objektu a s jejich výsledkem se nic nedělalo, použití atributů bylo asi o 10% rychlejší (bez kopírování výsledku to bylo asi 0,97 sekundy a ta druhá funkce měla 1,05). Pokud se s těmi hodnotami pak mělo dál pracovat, objektová režie pohltila ten rozdíl a obojí bylo zhruba stejně rychlé.
A když se ten druhý kód použil jako funkce mimo objekt, byl nepatrně rychlejší.

(Poznámka, tenhle příspěvek jsem napsal a zapomněl odeslat, tak ho odesílám teď)
1Pupik1989
Profil
Joker:
Jestli to dělá pro každý pixel obrázku, může se to dělat i víckrát.

V tomto případě to zjevně vypadá, že je to na každý pixel a už při obrázku 200x100 pixelů to asi bude znát.

Já to zkoušel pouze v javascriptu, ale tam je to spíše dle cpu, takže to nemůžu porovnat.

Přeportování na PHP mi bude asi chvilku trvat. Nicméně bych tím mohl opravit i hlášku co tu nejspíš dával dnes autor, že PHP GD neumí přečíst víc jak jeden IDAT chunk. Na to už mám knihovnu připravenou (sice v JS). Pokud to tvůrci PHP ještě nemají s libpng vyřešené, tak doufám, že se jim to v budoiucích měsících bude líbit, jelikož je to stará hláška.
Oxidián
Profil *
Poznámka - spouštím script na starém pc takže se mi zpracovává déle. Pokud si stáhnete můj script, tak nemusíte nic programovat a uvidíte sami. Ale pro porovnání v režimu SUPERFAST false je třeba ještě nastavit index do původního stavu:
$po->pixelOperation($_GET['image'], 'result_noise.png', array($po,'addNoise'), $noise);

Tu svoji metodu bych otestoval dneska, takže mohu pak udělat porovnání.


    if (SUPERFAST) 
     $po->pixelOperation($_GET['image'], 'result_noise.png', 'addNoise', $noise);
    else
     $po->pixelOperation($_GET['image'], 'result_noise.png', array($po, 'addNoise'), $noise);
Oxidián
Profil *
Index:
http://paste.ofcode.org/bmp4KJwqkC9kfintV4KzrE

converter_class.php
http://paste.ofcode.org/Ks2DH54usUWSBM2C7C9Ldt

exceptions_class.php
http://paste.ofcode.org/FRkSPjG2p55c68cVBbwva5

Image_PixelOperations_class.php
http://paste.ofcode.org/Juc8N93SUZJw6PBZqXXd6v

Poznámka, tato verze běží bez chyb jen v SUPERFAST true.

Testoval jsem celkem tři druhy podmínek, které určují kdy se má cyklus přeskočit. Pokud dojde k přeskočení tak barva je ve výsledku černá, protože jsem to neošetřil. V testech jsem používal vždy buď token $lessSingle nebo $greatSingle, je možné provádět i jiné druhy testů, ale já se zaměřil jen na saturaci o hodnotě 53%. Tak6e buď je saturace větší nebo menší a podle toho se barva vyřadí (zčerná) nebo nevyřadí. Dochází tak např. k nahrazení červených a hnědých barev ale černé a bílé barvy jsou přepsány šumem. Správně fungoval jen můj test (alespoň se domnívám - a domnívám se že to je proto, že např. pupikovo řešení neobsahuje situaci, kdy jsou dvě barvy rovné - například v mém případě jsou červené barvy 255 0 0, černé barvy 0 0 0, taky je tam modrá 33,1,255 - prostě obyčejné schéma kreslené asi v mspaint).

Výsledky:
New times (no exceptions module):
1.53328895569
1.39514279366

Times with exceptions module using reference to instance:
+ moje funkce setMinMax($R,$G,$B)
A) conditions: less then + interval exceptions
2.14165282249
2.28813385963
2.16604995728
2.2437331676
B) conditions: greater then + interval exceptions
4.40966415405

exceptions module
+ getMinMax($R,$G,$B) - juriadovo řešení
B) Juriadovo řešení selhalo,
obrázek byl nahrazen černou barvou
čas zpracování

Zatím nic nedokazuje
A) greater then + interval ex.
4.54233002663
4.76259684563
4.52958917618

exceptions module
+ setMinMax2 - Pupikovo řešení
A) less then ... + interval ex.
2.46116709709
2.42923307419
2.46266818047
2.44993901253
Funkce ale není zcela správně, takže obrázek není kompletně vykreslen
B)
4.79987978935
4.83309817314
4.8145301342
4.87123084068
Funkce ale není správně, takže obrázek není kompletně vykreslen

Zdá se, že jsem vyšel nejlépe se svou porovnávací funkcí.
Oxidián
Profil *
Zjistil jsem ale další zajímavost. Když do té (vnořené) smyčky vložím toto:

if ($exceptionsToken):
  $this->convert->rgb2hsv($this->rgb,$this->hsv);

//$this->testTime($this->time1, $otime);
$ntime=microtime(true);
$this->time1 += $ntime-$otime;

  $otime=microtime(true);                                       
  if ( !$ex_single_sat->check($this->hsv->s) ) // vlož originální !!! saturaci 
      {
      $ntime=microtime(true);
      $this->time2 += $ntime-$otime;
      // $this->testTime($this->time2, $otime);

             continue;
       }                                
    if ( !$ex_interval_myImage->check($this->hsv->h,$this->hsv->s,$this->hsv->v) ) // vlož originální hue, sat, lightness !
             continue;
// $this->convert->hsv2rgb($this->hsv,$this->rgb);
endif;                

Tak se čas prodlouží o neuvěřitelné dvě vteřiny. Ze 4 to skočí na 6! Jen díky tomu že jsem se pokusil změřit čas mezi akcemi. Taky jsem zjistil, že když bych místo toho použil funkci
    function testTime(&$t, $o){      
      $t += microtime(true)-$o;    
    }
kterou volám v cyklu dvakrát, tak to opět stoupne o dvě desetiny, z 6.3 až 6.4s na 6.5 až 6.6s.

Dále jsem zjistil, že když kód z funkce setMinMax přesunu přímo do rgb2hsv tak se převod barvy rgb2hsv uskuteční o 1/4 rychleji! Dále když nepoužiju $this->min a $this->max ale $min a $max lokálně, tak se opět čas zkrátí o jednu desetinu z 1.5 na 1.4 v rámci této části.
Taky jsem zkrátil počet desetinných míst z 12 na 3 a opět zkrácení asi o dvě desetiny.

Tady jsou teď výsledné časy pro podmínku
A) Less then + interval
1.808
1.973
1.773
B) Great then + interval:
3.831
3.815
3.88

Z toho vyplývá že by se to dalo ještě urychlit, kdybych kód pro převod z rgb2hsv přesunul přímo dovnitř smyčky.
1Pupik1989
Profil
Opravuji druhé řešení, má to být:
$arr = Array($R,$G,$B);
sort($arr);

Jelikož sort vrací boolean.

První řešení je naprosto v pořádku. Otestováno a používáno už asi 5 let pro výběr nejmenších a největších souřadnic Y v trojúhelníku při perspektivní projekci.
Oxidián
Profil *
Joker:
Implementuju přímo do kódu bez volání funkce:
  $min = ($B < $G) ? (($R < $B) ? $R : $B) : $G;
  $max = ($B > $G) ? (($R > $B) ? $R : $B) : $G;
Čas v rámci použitého modulu podmínek Less then + interval
1.657
1.843
1.68
1.741
Tím si trumfnul můj nejlepší čas 2.14165282249! Gratuluji. Nicméně mi to pořád dává jiný obrázek než ta moje funkce. Že by ta moje funkce byla špatná v logice?


Oprava: můj nejlepší čas byl 1.773 až 1.808
1Pupik1989
Profil
Joker má chybu hned v prvních větvích else, protože už neporovná $R s $G

Takže:

//$min = ($B < $G) ? (($R < $B) ? $R : $B) : $G;
//$max = ($B > $G) ? (($R > $B) ? $R : $B) : $G;
  
$min = ($B < $G) ? (($R < $B) ? $R : $B) : ($R < $G ? $R : $G);
$max = ($B > $G) ? (($R > $B) ? $R : $B) : ($R > $G ? $R : $G);

Oxidián: Ty tam máš taktéž hrubku. Zkus:

$R = 100;
$G = 200;
$B = 5;


Co ti vyjde? Min: 200, max:200.
Oxidián
Profil *
1Pupik1989:
Mě se to zdálo nějak krátké. Nad tím jeho kódem jsem neuvažoval.

Výsledné časy u toho kódu teď:
A)
1.911
1.897
2.039
2.115
1.935

B)
4.371
4.51
4.256
4.35
4.45

Oproti mému:
A)
2.007
2.058
1.881
1.924

B) 4.354
4.44
4.572

Má to o jednu desetinu vteřiny rychlejší


1Pupik1989 dík za upozornění
Opraveno tak doufám, že to teď je správně.
http://paste.ofcode.org/ZZYsVSeewy6VGFpWWeafbb


Nejlepší časy:

Moje Funkce znovu opravená, po odstranění chyb a přidání & do druhého parametru funkce rgb2hsl():
A)
1.785
1.794
1.754
B)
3.706
4.093
4.109
4.1

Jokerův kód opravený pupikem
po přidání & do druhého parametru funkce rgb2hsl():
Krátký kód
A)
1.692
1.761
1.735
B)
3.697
3.872
3.811

Předním jsem neměl & v hlavičce. Já myslel že je jedno jestli tam to & je nebo ne. Objekty se v PHP mají předávat odkazem.

Zkrácený kód opět vede o desetinu až dvě.
Oxidián
Profil *
Když navíc přesunu kód z AddNoise přímo do
smyčky:

A)
1.686
1.748
1.739

B) 3.034
3.123
3.184
3.2
1Pupik1989
Profil
No metoda seMinMax2 je úplně jiná, než jsem psal.

Já to myslel takto:

private function setMinMax2($R, $G, $B) {
  $temp=0;

  if($G < $R){
    $temp = $R; $R = $G; $G = $temp;  
  }
   
  if($B < $R){
    $temp = $B; $B = $R; $R = $temp;  
  }
   
  if($B < $G){
    $temp = $B; $B = $G; $G = $temp;
  }
  
  $this->min = $R;
  $this->max = $B;
}
Oxidián
Profil *
Nakonec se mi povedlo dostat ještě lepší časy:
A)
1.384
1.454
1.426
1.438
B)
2.604
2.622
2.833
2.718

dohromady na převod rgb2val(): 1.291
dohromady na vyhodnocení podmínek Less then ... + interval... 0.03084

Rozdíl nastal poté co jsem z hlavičky funkcí pro převod odstranil objekty a místo toho používám

public function rgb2hsv($r, $g, $b, &$H, &$S, &$V)

Určitě by se to dalo ještě urychlit, kdybych přesunul kód z funkcí pro převod přímo do kódu. Je překvapující kolik se dá ušetřit času na zpracování pokud vynechám OOP struktury uvnitř smyčky a pokud kód zpracuju přímo, bez použití funkcí. Nicméně pokud chci mít více možností jakou metodou zpracovat obrázek, pak je otázka kolik času zabere vyhodnocení switch uvnitř smyčky - pak by snad dynamické volání metody vyšlo nastejno.

1Pupik1989
Aha, tak to jsem nepochopil.
1Pupik1989
Profil
if ($R < $G ){
  if($R < $B ){
    $min = $R;
    $max = $G < $B ? $B : $G ;      
  }else{
    $min = $B; 
    $max = $G;
  }
    
}else{
  if($G < $B){
    $min = $G;
    $max = $R < $B ? $B : $R; 
  }else{
    $min = $B;
    $max = $R;    
  }
}

Ha a jsem ještě rychlejší. :D
Oxidián
Profil *
1Pupik1989:
Poslední kód se vyhodnocuje za 2.7 oproti původnímu 2.75. Zdá se být trochu rychlejší. Bravo.
2.714,2.671,2.707,2.708
oproti
2.595,2.773,2.836,2.653 zkrácený kód.
1Pupik1989
Profil
On není zkrácený, jen jsem odstranil dvě zbytečné podmínky.

Mimochodem pořád tam máš chybu. Stále vychází 200:200.
Oxidián
Profil *
U jaké barvy? Já myslím že jsem u sebe chybu opravil. Odstranil jsem třídu pixel, teď budou časy rychlejší. S posledním kódem: A) 1.432, 1.317 B) 2.564, 2.57


A) 1.334, 1.339, 1.388 B) 2.508, 2.603
S každou třídou kterou odeberu se to trochu zrychlí ve výsledku


A) 1.324, 1.41 B) 2.547, 2.762, 2.631


Chtěl jsem vyzkoušet goto RGB2hsv; ale bohužel mám nižší verzi PHP :-( Tak nic. Tenhle test už nedám. Myslíš že by to bylo rychlejší když bych použil goto místo volání funkce?
1Pupik1989
Profil
goto zásadně nepoužívám, takže ti moc neporadím.

V kódu z [#18] Oxidián máš v první vnořené podmínce chybu na řádku 75.

Jinak jsem hrábl do archivu, kde jsem měl napsané filtry pro PNG. Tak nejmenší ze tří vybírám následovně.

if ($R < $G ){
  $min = $R;
  $max = $G;
}else{
  $min = $G;
  $max = $R;
}  

if($B < $min){
  $min = $B;
}elseif($B > $max){
  $max = $B;
}

Pomalejší to o tolik není a vzhledem k poměru délka kódu/rychlost je to ideální.
Oxidián
Profil *
1Pupik1989:
Jo, ale tu funkci už dávno nepoužívám. Psal jsem že jsem ji přesunul přímo do funkce rgb2hsv aby to jelo rychleji. Podívej se na řádek 127, tam je to opravené. Délka kódu mě nezajímá, přednost má rychlost. Pokud je goto účinnější než volání funkce, tak ji klidně použiju, ale až od novější verze php. Já myslel že to je zastaralé a že to php už možná přestalo používat. Podíval jsem se do manuálu a zjistil, že je to naopak, že se ke goto naopak v php 5.3 vrátili. Asi zjistili, že to má nějaké svoje přednosti.
juriad
Profil
Oxidián:
Pokud žádáš vysokou rychlost, tak to napiš v nějakém rozumném jazyku (Céčku). Tam se prakticky nemusíš starat o tyto drobné optimalizace, spoustu toho zvládne kompilátor sám.

goto je konstrukt, který ve většině případů vede k hůře spravovatelnému kódu. http://en.wikipedia.org/wiki/Goto#Common_usage_patterns_of_Goto. Goto je rychlejší než volání funkce (alespoň v Céčku), ale neumožňuje ti vrátit se zpět, tedy ve výsledku bude simulovat inlining, až na to, že se navíc (zbytečně) dvakrát skočí.

Když už řešíš, jestli použít goto z důvodu výkonu, nechtěl bys také rozbalit smyčky? Také to přidá nějaké to promile výkonu. Nevýhodou těchto postupů je, že vznikají strašné duplicity kódu a ukazuje se, že je často levnější koupit další server, než zaplatit programátora, který to zoptimalizuje až na doraz a který to pak bude udržovat.
Oxidián
Profil *
juriad:
Rozbalení smyčky - pokud by to bylo pro jeden menší fixní obrázek o fixní velikosti např. 256x256 px, tak by to šlo. Ale bylo by třeba 256x zopakovat vnitřní smyčku :-) Pochopil jsem tě správně že tato konstrukce použitelná na výběr metody by uvnitř smyčky nefungovala?

// iniciace - předej požadované metody, které chceš vykonat
$args=array('brightness','balance','selectColor','blur');
function initiate($args)
{
  global $s=''; // pořadí funkcí bude např. $s='4132'; 4 metody na zavolání
  global $c=count($args);
  foreach($args as $arg):
    switch($method):
      case 'balance': $s[]=1;break;
      case 'blur': $s[]=2;break;
      case 'selectColor': $s[]=3;break;
      case 'brightness': $s[]=4;break;
    endswitch
  endforeach;
}

initiate($args);
// zde otevřít a načíst obraz ... a pak projít
for (y=0;..): // vnější smyčka
  for (x=0;..): // vnitřní smyčka
    $i=0;
    label0:
    $methodname="method".$s[$i];
    goto $methodname;
    goback1:
    label1:
    $methodname="method".$s[$i];
    $gobackname="goback".$s[$i];
    goto $methodname;
    goback2:
    
    label2:
    $methodname="method".$s[$i];
    $gobackname="goback".$s[$i];
    goto $methodname;
    goback3:
    
    label3:
    $methodname="method".$s[$i];
    $gobackname="goback".$s[$i];
    goto $methodname;
    goback4:
    
    label4:
    $methodname="method".$s[$i];
    $gobackname="goback".$s[$i];
    goto $methodname;
    goback5:
    
    method1:
    $i++;
    // zde udělej co je třeba
    goto $gobackname;
    
    method2:
    $i++;
    // zde udělej co je třeba
    goto $gobackname;
    
    method3:
    $i++;
    // zde udělej co je třeba
    goto $gobackname;
    
    method4:
    $i++;
    // zde udělej co je třeba
    goto $gobackname;
    
  endfor; // konec vnitřní smyčky
endfor; // konec vnější smyčky

Neotestoval jsem to je to jen představa
juriad
Profil
Oxidián:
Ano, nefungovala by, skákat můžeš pouze na návěští a prostor názvů návěští je v PHP (ale i jiných jazycích) úplně oddělený od všeho ostatního. Goto vyžaduje jako svůj argument název návěští, nikoli řetězec.

Smyčka se nemusí rozbalit úplně, můžeš třeba počet provedení jen snížit na osminu - v těle se provede osm příkazů místo jednoho. Dělá se to z důvodu ušetření skoků, které při špatné predikci způsobí zahození pipeline v procesoru za cenu nárůstu délky programu. V případě, že se celá smyčka nevejde do instrukční cache, tak si výkonově pohoršíš. Toto jsem spíše nadhodil, aby sis uvědomil, že touto cestou jít nechceš, ale jak koukám, moc se to nezdařilo.

U interpretovaných jazyků jako je PHP může jedna optimalizace pomoct v jedné konkrétní verzi PHP, ale naopak uškodit jinde/jindy. Kdybys to implementoval jako Céčkový modul, tak bys dosáhnul mnohem lepších stabilních výsledků.

Co tě vůbec vede k tomu, používat na výkonové věci PHP? Je to jediný jazyk, který umíš? Snažíš si „ušetřit“ práci?
« 1 2 3 4 »

Vaše odpověď

Mohlo by se hodit

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0