<b>Programátorské cvičení č.2</b>

heh, moc nechápu co píšeš :-))

Nevím, jak moc jsou skripty programátorsky odfláknuté, nevím jak se tohle pozná :-)) Ale uznávám třeba, že ten můj se vyznačuje tím, že řeší daný problém a nic víc, ani jsem to nerozdělil do funkcí a ve funkci používám globální proměnné...je prostě jen kód, není to něco připravené na integraci do stránek, je to jen vyjádření myšlenky převedené do kódu :-)

Tomík i Richard to od pohledu řeší podobně jako já, nevím jestli jsou v těch kódech nějaké výrazné rozdíly, jsem líný to procházet, ale myslím že to bude podobné, nějaká ta rekurze, nějaké třídění a je to...

Ten Jakubův skript jsem na první pohled nepochopil a nechce se mi ho dopodrobna procházet... :-)))

Zkusil jsem to tak nahrubo otestovat tím, že jsem to nechal natřikrát běžet 2000x za sebou (teda tu část kde se něco dělá, ne celý skript, protože tam je pak problém s deklaracema fuknckí atd.). Nevím, jestli je to rozumný způsob testování, každopádně výsledky jsou:
Richard: 8/10/12 s
Jakub: 3/4/4 s
RUR: 0/1/1 s
Tomík: 3/3/3 s

viz
http://rur.kx.cz/prgcvic2-2000/
(kde se něco vypisuje nebo ukládá do proměnné pro vypsání, nahradil jsem to tečkou, aby nebyla plná stránka textu; rozdíl mezi časem na začátku a na konci je dole na stránce)
peta:
hele, možná že sis nevšiml, tak ti to trošku připomenu:
Tady NEJDE o nějakou přiblblou validitu, ale o funkčnost, blbuvzdornost, rychlost, ... Možná proto je to v sekci PHP a ne HTML?!

R.U.R:
vůbec není podezřelý, že když jsi to testoval, tak zrovna tvůj kód byl nejrychlejší... ;)
no taky si řikám :-)) ale snažil jsem to dělat spravedlivě, vymyslel jsem jeden způsob testování a takhle to vyšlo. ale třeba to má nějaké mouchy, tak budu rád, když to někdo otestuje třeba nějak jinak a hodí jiné výsledky...:-) nejlepší by asi bylo prostě to pustit jednou na větší data, ale nechce se mi je vymejšlet...
Teoreticky ty casy souhlasi. Shodou okolnosti i minule Richarduv kod byl vyrazne nejpomalejsi (Richarde promin ;)). Ale kdyz porovnam treba ten muj a R.U.R., tak bych rek, ze R.U.R. by mohl byt rychlejsi, ponevadz tam treba pouziva funkci ksort pouze jednou, kdezto ja nekolikrat.
<HTML>A sakra :)
Jsem totiz clovek co napred neco udela v co nejrychlejsim case a teprve potom meri rychlost a optimalizuje tam kde je to nutne.

Nicmene kod od Petra aneb drag&drop strom je uplne mimo zadani a bez ukladani je to i k nicemu. To ze muj kod neni validni jsem zjistil tehdy, kdyz jsem pouzil tento vypis v praci a projel to validatorem, opravit to je otazka 1 radku.</HTML>
no, to jen tak vypadá, ve skutečnosti je ten Ksort v cyklu foreach, takže se provadí několikrát ;-)) takže nevím, myslím že by to měl ěště zkusit někdo změřit nezávisle na mě...
já jsem to taky vymyslel, udělal, otestoval a poslal, nedělal jsem žádné post optimalizace...
R.U.R: mě to nějak nedalo, tak jsem to zkusil poměřit taky a bohužel jsem došel k odlišným výsledkům :|

Postupoval jsem asi takhle: věřil jsem všem skriptům, že pracují tak, jak mají a proto jsem nechal PHP náhodně vygenerovat pole o 2000 subpolích ("idup" se vybíralo náhodně, "pos" se přidávalo podle počtu "idup"). Skript na generování jsem si já vůl bohužel smazal, takže není k dispozici a psát se mi s ním znovu nechce.
No a projel jsem každý z kódů 3x a výsledky jsou tyto:

# Jakub: 2,72687101364 | 2,5752530098 | 2,98580813408 || avg 2,762644052507
# Tomík: 2,65696907043 | 2,61306214333 | 2,48302006721 || avg 2,58435042699
# Richard: 0,974295139313 | 0,992434024811 | 1,02457904816 || avg 0,997102737428
# RUR: 2,254068974523 | 2,564471650751 | 2,688672591004 || avg 2,502404405426

Jako dodatek: pokud jsem nastavil error_reporting na E_ALL, ak mi Tomíkův kód vysypal úžasné množství Undefined variable $tmp a $out, takže to potom trvalo 10+ vteřin.

Testoval jsem na: P4 2,4GHz HT, 2GB Ram, Apache 2.0.59, PHP 5.2.5

Takže kdo z nás je pravdě blíž? ;)
Juchu :)
No jo no. Nemam definovany promenny. Tak si je tam nadefinujte ;)
Myslím, že tyhle výsledky by měly být objektivnější (i když záleží taky na tom, jestli ta vygenerovaná data vypadakla nějak pravděpodobně...)

Jinak velice překvapivé jsou podle mě výsledky Richarda, pokaždé na jiném konci :-D Jinak pořadí zůstalo zachováno, jen se mi zmenšil náskok :-))
Popravdě řečeno výsledky Richardova skriptu se mi taky zrovna dvakrát moc nezdají. Ten kód není zase natolik odlišný (v podstatě je princip u všech obdobný, liší se hlavně zápisem a drobnostmi), aby dokázal být o víc než půlku rychlejší než ostatní. Bohužel jsem si já idiot testovací skript smazal, takže nemůžu výsledky znovu projet :/

Jinak pole bylo, jak jsem psal, strojově vygenerováno. Pokud se někdo budete snažit o podobnou věc, princp byl zhruba takovýto:
ID se bralo jako výsledek funkce count($pole)
TITLE byl MD5 hash náhodného čísla => md5(rand(100, 999999))
ID_UP se vybíralo náhodně z čísel 0 - 30 => rand(0, 30)
POS se bralo tak, že se spočítaly všechna subpole, která mají ID_UP rovno aktuálnímu a přičetl jsem k tomu 1.
Nebylo to zase až tak složitý, ale asi mi leniví mozek, protože se mi nad tím nechce přemýšlet znovu ;)
R.U.R. (jsrosa.wz.cz)
Jake verze jssi pouzil PHP?
Ono php5 muze mit neco optimalizovane. Pripadne kazdy muzete mit povolene jine veci v nastaveni.
A pozor, vypinejte winamp a podobne veci :)

Mi se treba ten Markuv kod libi pro minimum instrukci.
Seradil si cele pole podle ID do jine promenne a potom neprohledaval cele pole, ale jen 0-n .
Coz je rychlejsi nez pro nahodne generovane pole, jako je treba toto forum, kde dane id muze byt az nekde uprostred.

Kazdopadne je mozne neco vygooglit, treba na vikipedii, kdyby zalezelo na rychlosti.
testoval jsem to na IC.cz
Zdravim...nasel by se nekdo ochotnej, kdo by napsal skript, ktery by seradil polozky menu tak jak jdou za sebou? (zadny vystup s html seznamem) ja jsem se zmohl jen na dvou-urovnove serazeni coz je spatne. diky
Skoda ze jsem si toho nevsiml drive..

Diky linknuti tohoto dredu na IRC jsem si toho vsiml a napadl me jednoduchy skript na par radku, ktery by toto vyresil. Linknu ho primo sem, uz je davno po uzaverce tak to snad nevadi. Skript jsem napsal behem asi 15ti minut vc. hledani toho spravneho sortu:

http://ondraster.czweb.org/pole.php
a zdrojak:
http://ondraster.czweb.org/pole.phps
A jeste aby to bylo vc. toho, kolikaty v zanoreni to je, tak radek:

echo '<ul><li>' . $jeden['title'] . '</li>';

staci upravit na:
echo '<ul><li>' . $jeden['title'] . ' (' . $id . ')</li>';

Snad to je komplet a vse to splnuje (vc. rychlosti - zadny kus neprojizdim dvakrat ve vypisovacim cyklu, v pripade 20ti polozek projedu dohromady 40ti polozkama - kazdou dvakrat.)
Tak se omlouvam, prave jsem si vsim, ze RUR ma totez, akorat ksort provadi v dalsim cyklu..
lze to vubec seradit jak jsem chtel ja? tj tak aby byly polozky za sebou tak jak se budou vykreslovat
patka: Nejak nechapu co chces serazovat. Jestli ti jde o to vypis, ktery se generuje, ale bez tech HTML znacek, pak staci ve vystupu tyto znacky vyhodit.
Teba v mem skriptu staci vyhodit radky $out = "<ul>\n"; a nahradit tento radek:
$out .= "<li>{$tmp[$i]['pos']} - {$tmp[$i]['title']} ({$tmp[$i]['id']})</li>\n";
timto:
$out .= $tmp[$i]['title'] ."\n";
Timto ziskas neformatovany odradkovany seznam.
Tomík: to je presne ono..dik. ja jsem byl linej ty skripty prochazet takze jsem nezkoumal jak to funguje a za to se omlouvam
nevim proc se zadani tyka zase poli, nemuzete dat neco noveho?
Budulínek (osvk.wz.cz)
Ze jo? Normalniho, bez class a tak :) Tyhle nejasne rekurzivni scripty mne dost stvou. Vubec se nerekne, co je vstup, co je vystup, jen to proste nejak udelej.
Na druhou stranu maji to pekne :)