[ Teorija ] "premature optimization is the root of all evil"

Prezgodnje karkoli je vedno vzrok za največ težav in največje težave, saj začetni koraki vedno pogojujejo naslednje korake. Posledično to pomeni, da je odpravljanje procesne napake, ki se je pojavila v začetnem koraku najtežje, saj to povzorči ponovitev dela na vseh naslednjih korakih. Težava je samo v temu, da ni možno natančno določiti kdaj je primeren trenutek za uporabo nekega postopka, v trenutku same odločitve. Pravilna ocena, da je bil nek postopek uporabljen prezgodaj ali prepozno, je možna šele takrat, ko je celoten proces zaključen, oziroma, ko pride do težav pri izvedbi procesa.

Ergo: če se je z optimizacijo začelo, in, če je ta optimizacija povzročila težave v nadaljnih korakih, potem je bila optimizacija vsekakor prezgodnja (premature) in posledično tudi izvor težav v procesu razvoja. Če pa optimizacija ni povzročila težav, to pomeni, da ni bila prezgodnja, kar seveda pomeni, da to ni bila "premature" optimizacija. Vsekakor je stavek "premature optimization is the root of all evil" verjetno vzet iz konteksta, s čemer je njegova sporočilna vrednost postala enakovredna stavku "Ta stavek je resničen." Stavek samega sebe izpolnjuje, saj je njegova sporočilna vrednost enaka ne glede na to, ali se odločimo, da je stavek resničen, ali pa ne. Če je bila optimizacija prezgodnja je povzročila težave, kar pomeni, da prezgodnje optimizacije povzročajo težave. Na drugi strani pa težav morda ni bilo, kar pomeni, da optimizacija ni bila prezgodnja, kar seveda pomeni, da ni mogla biti vzrok težavam.

Veliko bolj zanimivo pa se je pogovarjati o optimizaciji sami: Kdaj je optimizacija smiselna? Kakšna optimizacija je smiselna? Ali optimizacija poveča kompleksnost procesa? Ali optimizacija vpliva na zasnovo testov? Na kateri točki je primerno vpeljati optimizacijo? Kako optimizacijo nadzorovati? Kako vrednotiti stroške optimizacije glede na izboljšane rezultate? Ali je dopustna optimizacija, ki spreminja semantiko sistema? in še in še in še....

Ali lahko vnaprej definiraš kdaj je preveč zgodaj? Konec koncev se optimizacijo ne dela samo v kodi, kot jo vidi večina ljudi, optimizacijo se lahko izvaja že pri načrtovanju sistema. Ali je to prezgodaj ali ne, pa je velikokrat težko povedati vnaprej. Samo če gledaš odločitev za nazaj (hindsight is 20-20) lahko zagotovo rečeš, da je neko prihodnjo težavo povzročila optimizacija. Če jo je, je bila optimizacija prezgodnja. Če je ni, potem optimizacija ni bila prezgodnja.

Kar se tiče pa stavka, pa bom vedno vztrajal, da se stavke vsaj v kontekstu programiranja gleda samo dobesedno. Če govorimo o nekih delovnih postopkih pri razvoju programske opreme, potem ne govorimo o "Jožetu, ki bo zril en jarek," temveč govorimo o "uporabi rovokopača s katerim bomo na trasi od A do B izkopali 120cm globok in 60cm jarek." Če nekdo napiše ekvivalent "problematične odločitve povzročajo probleme," je napisal natančno to. Nikakor pa ni napisal "nekatere odločitve povzročajo probleme - imenujemo jih problematične." "Prezgodnja optimizacija povzroča težave" nikakor ni isto kot "če začnem optimizacijo zelo zgodaj, bom imel težave - optimizacija je lahko prezgodnja." Če programiraš, potem ne ugibaš, temveč definiraš in se trudiš biti dosleden. Če ne znaš niti vprašanja postaviti natančno in čim manj dvoumno, potem imaš tudi z odgovori težave.

ta izjava definitivno ni genericna, in je po pravici povedano pobrana z gamedev.net, kjer z njo "proji" strasijo zelence ;)

in naceloma se precej strinjam s teboj BW. kot c++ programer prekleto dobro vem, da "kr zacet kodirat" je velko sranje. ce se le da (in se mora!) je treba zadeve najprej narisat ter premislit kako problem resit z cim manjso porabo (mem, cpu). kot tak sistem zalaufa, pa po potrebi stopi v igro se drug korak optimizacije... to alpa rewrite kode ;)

ampak ponavadi pa izjava leti na zacetnike v programiranju (no offense firestorm), ki se prevec ubadajo sz samo kodo, kot pa dejanskim problemom.

Na optimizacijo je pametno paziti že pri sami zasnovi programa - lahko to precej bolj vpliva na hitrost, kot potem natančno pisanje posameznih funkcij.
Seveda je pa tudi odvisno od problema. Če je stvar dovolj zapletena, da na začetku težko predvidiš vse in je treba še precej spreminjati stvari, potem je bolje, da ni preveč optimizirano, ker je laže popravljati.

Nekaj bo že na tem, saj za tem stavkom (poleg Vesoljca in še koga) stoji nihče drug kot veliki D.E.K. Vendar je izjava v resnici izvzeta iz (časovnega) konteksta.

link, lank

Tale tema je "rekurzivna". Bomo že na začetku vseh programiranj optimizirali potek?

Če se bomo recimo odločili, da je prezgodnje optimiranje zlo, smo tako optimizirali vsa bodoča programiranja, saj se prezgodnjih optimiziranj ne bomo šli.

Ovbe, ovbe ... s tem smo zagrešili eno zgodnjo optimizacijo, ergo greh.

Če se bomo pa odločili, da se zgodnje optimizacije vendarle smemo iti, potem - potem smo se paradoxu izognili. LAHKO se jih gremo.

Tko.

Ta izrek ima svoje diametralno nasprotje, ki se ga na žalost trenutno ne spomnim. Pomen slednjega je v tem da se optimizacijam v smeri algoritmične časovne kompleksnosti ne smeš izogibati, ostale optimizacije pa so odvečne in potencialno škodljive.
Sicer je že Darko več ali manj razložil.

edit: typo.

Po mojem pa tudi pri CPU zahtevnih operacijah ASM še ni izpadel iz igre. Compilerji še vedno niso tako hudimano dobri ko pride do milijona različnih varijant SSE... Ne boš pa šel zato pisat pol programa v ASM-ju.

Ce se prevec osredotocis na optimizacijo v zacetnih fazah aplikacije, potem v bistvu bolj malo razmisljas o dodatni funkcionalnosti in nimas nekega celotnega pregleda. Pa verjetno tudi cas izgubljas ko se igras z optimizacijo, ko se program ni niti koncan.

najbolj važno je, da program nima hroščev (se ta beseda uporablja v slovenščini?). najbolje je v začetku vse, vključno s hitrostjo in porabo spomina, premisliti in narediti kompleten in natančen načrt programa. jaz bi rekel da je "izvor vsega zla" programiranje brez načrta ali pa s slabim načrtom. programiranje je treba razdeliti na dva dela: na delanje načrta in pisanje kode, in delanje načrta mora biti težje kot pisanje kode.

jaz bi rekel ravno nasprotno, da je izvor hroščev (i.e. zla) ravno preveliko popravljanje kode naknadno, oziroma mišljenje, "bom že kasneje popravil". od začetka je treba misliti na vse, to pa se da narediti z dobrim načrtom.

>"Od začetka preprosto ne moreš ne misliti na vse ne zajeti vseh zahtev uporabnika (ki jih tako ali tako tipično še sam ne pozna)."

Ne mešati stvari. Če programer ne ve, kaj bi uporabnik rad, potem je to drug problem. Mogoče v komunikaciji, ali pa si mora uporabnik prej razjasniti, kaj bi rad. Obenem praviš, da ne moreš misliti na vse zahteve uporabnika? Zakaj pa ne? Sigurno lahko narediš seznam stvari, ki jih mora biti program zmožen opraviti, in to je potem osnova za načrt.

Katere pa so še tiste "lepo zveneče teorije, ki v praksi izzvonijo v prazno"? Jaz sem iz svojih izkušenj prišel do zaključka, da prej rabim dober načrt. Ne programiram več drugače (razen lahkih programov, tam lahko fušaš, bo vseeno.) Če gledaš izvorno kodo programov, jih je tudi zato težko razumeti, ker so brez generalnega načrta. Npr. theory.txt bi moral biti priložen vsakemu delu kode, ki je neodvisen od drugih delov kode.

Uporabnik ne ve kaj hoče. Vsaj dokler tistega ne dobi. Potem reče da ne mara ali pa reče "še mi tko delej!". V tisti fazi ima verjetno tudi kakšno zelo tehtno pripombo ali idejo.

Za vse pa ne boš naredil nikoli. Izberi samo en del uporabnikov, ki govorijo tvoj jezik.

Pa razvijaj zadevo ob povratnih informacjah tvojih strank.

Vsaj 33% jih raje pošlji h konkurenci, da njej zaserjejo vse.

Ker nisi ne Bog, ne Microsoft.

Čeprav prodajaš "samo kruh", je bolje da vseh ni v tvojo štacuno. Z enimi je zguba, drugi bi slabo vplivali na okus tvojih pekarskih izdelkov ...

Čez 50% trga se ne splača hodit.

Kadar se optimizira kodo, se mora vedno vedeti kakšni natančno so cilji optimizacije. To pa zato, ker je cena za optimizacijo kode največkrat žrtvovanje osnovnih načel dobrega programiranja, če ne kar pravilnosti delovanja za vse možne vhodne podatke. Vsaka optimizacija programske kode lahko pripelje do novih napak v delovanju in bolj kompleksne kode, ki vedno manj odraža dejanski postopek - algoritem. Bolj kompleksna koda je tudi manj razumljiva, zaradi česar jo je tudi težje vzdrževati ali pa uporabljati pri drugih aplikacijah. Zaradi vseh teh negativnih lastnosti vsake optimizacije kode, je ta, v večini življenskih situacij, nepotrebna saj imajo jasnost, preglednost in (vsaj približno dokazljiva) pravilnost prednost pred običajno malenkostnimi pridobitvami optimizacije programske kode.

Vsekakor pa je optimizacija dobra in dobrodošla tam, kjer je možno jasno demonstrirati, da je potrebno hitrejše (cpu) ali učinkovitejše (mem, I/O) delovanje programa, optimizacija pa privede do zelo opaznih razlik v delovanju. Če imamo algoritem, katerega zahtevnost je O(n²), potem lahko z optimizacijo pridemo iz npr. 10*n² na 5*n². To pa nam pomaga obdelati nekaj več podatkov v nekem doglednem času. Če pa za isti problem obstaja algoritem zahtevnosti O(n), ali pa celo O(Log(n)), tega pa načrtovalec (in ne programer) ne ve, ali pa ne zna, potem takšnega smetja ne morejo rešiti niti največji herojski napori programerjev, ker bo O(n) algoritem pri zadostni količini podatkov vedno prekašal O(n²) algoritem*.

Če je sistem/aplikacija pravilno načrtovana, potem je potreba po optimizaciji resnično minimalna. Če pa ta potreba obstaja, se jo da včasih uganiti, ne pa vedno. Načrtovalec sicer lahko izbere pravilne algoritme in pristope, na koncu pa lahko še vedno pride do problemov, ki lahko zahtevajo optimizacijo. Če pa programer dela optimizacijo "na rezervo", pa lahko takšen programer IMO fuša in se uči kje drugje, ne pa na produktih z znanimi zahtevami in roki. Takšna brezciljna optimizacija je navadno strup, saj vedno naredi veliko škode, dobički pa niso nikoli ne vidni, ne dokazljivi.

-----
* Kot ilustracijo lahko dam primer, ko je nek kandidat algoritem prostorske zahtevnosti O(n^a) optimiziral tako dolgo, da mu je uspelo v nekaj GiB RAM-a rešiti nekaj, kar običajno porabi nekaj 10 GiB RAM-a. S tem ni spremenil prostorske zahtevnosti algoritma, temveč je samo herojsko podaljšal njegove "muke". Drugi kandidati so našli algoritem prostorske zahtevnosti O(n), z njim pa so problem rešili v nekaj MiB. Čeprav je dokazal, da optimizacijo resnično obvlada, takšnega načrtovalca pač ne potrebujemo.