Nedá mi to, abych taky nepřispěl svojí troškou oleje do ohnivé mlýnice:
Dne 31. července 2010 21:06 "Zdeněk Troníček" <troni...@fit.cvut.cz> napsal(a):
> Pokud chcete optimalizovat, pustte profiler na funkcni program, najdete
> misto, kde program travi vetsinu casu ("measure, don't guess") a pak
> optimalizujte.
Toto tvrzení je plně eqivalentní k hypotetickému Rychlonožkovu
zvolání: "Wirthův zákon na vás, plantážníci!"
Úplně na rovinu se přiznám, že mám s tímto přístupem poměrně hodně
velký problém. Vlastně dva.
a) toto je přesně zdrojem takových bastlů jako jsou ohnivá liška a
otevřená opice.
Na nejrychlejším počítači, co mám, liška neběží, nýbrž se plazí, a u
opice čekám někdy i několik sekund,
než se uráčí přepnout mezi dvěma listy či překreslit graf. A pak při
dalším, výrazně rychlejším (některé operace se zrychlí klidně i
desetinásobně) vydání se objeví několik nových vychytávek, které opět
srazí výkonnost do kolen
b) trošku mi to připomíná schizofrenii jednoho známého webdesignéra.
Dostal za úkol vyvinout velkou JavaScriptovou aplikaci. Vyvíjel ji na
MACovi a safari a za pár měsíců byla téměř hotová. Chybělo posledních
pár bezvýznamných nedodělků, když dostal za úkol rozchodit aplikaci i
na ostatních prohlížečích. Chrome mu zabral den (používá také WebKit),
Opera fungovala, s ohnivou liškou se mořil dva týdny a MSIE nedal
vůbec. Qůli MSIE pak musel tuto aplikaci celou přepsat... Prostě "bad
by design", neboli jak říkáme tu u nás - z hovna tatar neuděláš. Velmi
obdobně to skončilo s NetScapem (mozilla byl kompletní přepis, skoro
všechno se zahodilo). Ve světě Javy tu máme dva exemplární příklady
kompletního přepisu qůli výkonnosti: Xerces a Axis.
Čitelnost je samozřejmě VELICE důležitá. Nelze ji ale prosazovat za
každou cenu. Mohu-li pro numerický výpočet hodnoty použít Newtona,
proč místo toho používat čitelnější půlení intervalu? Proč třídit
prostým hledáním prvků od největšího po nejmenšího, když jsou tu
bublina, QuickSort či MergeSort?
A ano, dobrovolně se přiznám, že mojí libůstkou v IntelliJ je živá
šablona ritar místo itar. Pokud nevíte, o čem je řeč, tak živá šablona
je na požádání (onou zkratkou a stiskem tabelátoru) vygenerování části
kódu podle šablony. Typicky se to používá pro generování iterací.
ITeration over LIst (itli) ITeration over ARray (itar) a Reverse
ITeration over ARray. Při klasické iteraci for (int i=0; i<N, i++) se
provádí v každém kroku porovnání oproti hodnotě (odečet plus test na
znaménko), kdežto při for (int i=N-1; i>=0; i--) se provede odečet
pouze jednou a pak v každém kroku pouze test na znaménko. Naučil jsem
se to na superpočítačích a tak nějak mi to zůstalo, i když vím, že v
současné době to má pouze mizivý vliv na rychlost, pokud vůbec.
> Snazit se odhadnout, kde bude potreba optimalizace, je
> hadani a i ti, kteri rozumeli mailu Ladi Thona v tomto vlaknu, by meli
> uspesnost takoveho hadani pravdepodobne nizkou.
Nesouhlas. Stačí k tomu léta praxe v roli archtekta a k tomu navíc
praxe v roli oponenta kódu :-D (Oponent Kódu je úžasná vymoženost.
Každý první pátek v měsíci dostane oponent od kolegy kód napsaný za
poslední měsíc, přes víkend si tím prolistuje a v pondělí ráno si na
max hoďku (bohatě stačí, ale qůli pochopení API musí být oba ze
stejného týmu) spolu sednou a prodebatují onen kód. Má to čtyři úžasné
dopady: kód se dokumentuje, píše pokud možno čitelně (dyk já budu taky
dělat oponenta, takže vím, jaký kód bych chtěl vidět), člověk má
zpětnou vazbu (a proč jsi to napsal takto blbě?) a hlavně roste
truckfactor. Obzvláště ve velkém týmu, kde každý maká jak barevný
pouze na tom svém kusu kódu, je to velmi užitečné.)
> Navic, dokud neni potreba
> optimalizovat, nema smysl nejakou optimalizaci delat.
Člověku, který toto prohlásí, patří vytahat za uši. A možná i
preventivně každé pondělí ráno.
--
Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com
