Kada performanse nisu odlika kvaliteta?

Insistiranje na performansama često može da asocira na druge manifestacije potrošačkog društva koje potiskuju racionalne elemente zarad zadovoljavanja potrebe da imamo nešto novije, lepše ili brže. To je naročito izraženo kod mladih kolega koji su željni dokazivanja ili su im još sveže akademske diskusije o tome šta je brže ili šta zauzima manje memorije.

I sam sam često bio žrtva tog poriva, potrebe da demonstriram trud i posvećenost poverenom poslu. Čak i suočen sa čuvenom izjavom o prevremenoj optimizaciji, nisam u potpunosti razumevao njen domet i vrednost. Kao što kaže Donald E. Knuth:

Premature optimization is the root of all evil (or at least most of it) in programming.

Pažnju posvetite dizajnu i lako razumljivom kodu – bez bespotrebnih funkcionalnosti

Jedan od sjajnih primera optimizacije je i čuveni metod za računanje inverznog kvadratnog korena u Quake III Arena. U samo desetak linija koda vidi se sav sjaj i cena genijalne optimizacije – neophodna matematička osnova, kreativna aproksimacija, asemblerski intimna implementacija, izvanredni rezultati i kod koji je dovoljno kompleksan da se najčešće opisuje kao mističan (evil, hacking i wtf su termini koji se koriste u komentarima, a koji dodatno pojačavaju ovaj efekat).

Kao studenti, svi smo se divili genijalnosti koja stoji iza toga pri tome ne razumevajući zaista sve okolnosti i tražeći priliku za tako neko veliko delo o kome će generacije pisati.

Za trenutak zamislite da je jedan od nadahnutih kolega odlučio da primeni tu genijalnu ideju, sa malim izmenama, u sred neke metode od 800 linija koda, zanemarujući sve ostale aspekte kvaliteta softvera. Zamislite potom da vi treba da nađete i popravite bug u toj metodi. Baš u tom trenutku osetićete pravu cenu rešenja koje zanemaruje sve ostale kvalitete softvera za ultimativne performanse.

Da bi optimizacija bila pravovremena, njena vrednost mora biti računata zajedno sa cenom koju ćemo platiti. Ukoliko nismo u stanju da izmerimo ekonomske posledice, kako pozitivne tako i negativne, jedino što nam preostaje je da se oslonimo na smernice koje će nas sprečiti da upadnemo u tu zamku. To će u većini slučajeva biti sasvim dovoljno bez zahtevanja opsežnih analiza za svaku pojedinačnu situaciju.

Prvo pravilo je da performanse posmatramo kao najmanje važan aspekt kvaliteta sve dok se ne dokaže suprotno. To naravno ne znači da treba aktivno da se trudimo da zanemarujemo performanse ili da pišemo najsporije implementacije, nego samo da, kada smo suočeni sa dilemom, ne krećemo od rešenja koje ima bolje performanse.

Drugim rečima, u većini slučajeva više pažnje treba posvetiti tome da imamo dobar dizajn, lako razumljiv kod koji radi tačno to što treba, bez dodatnih funkcionalnosti. Prema Knuth-ovoj proceni to bi moglo biti sasvim dovoljno za 97% koda koji napišete. Onih preostalih 3% ćete vrlo lako identifikovati u procesu testiranja performansi (koje već radite, zar ne?), kroz nezadovoljne korisnike, kroz povećane troškove u cloud-u itd.

Kada identifikujete situacije u kojima performanse nisu zadovoljavajuće, zahvaljujući dobrom dizajnu i razumljivom kodu, lako ćete identifikovati module koje treba popraviti (već se isplati što smo stavili fokus na dizajn). Verovatno je slučaj da ima više od jednog mesta gde možemo popraviti situaciju. Pitanje je kako ćemo odabrati odakle da krenemo.

Uvek krenite od koda koji troši najviše resursa

Drugo pravilo je da optimizaciju uvek krenemo od koda koji troši najviše resursa kojih nemamo dovoljno (to ne mora uvek biti procesorsko vreme). Iako to možda deluje očigledno i trivijalno, iznenađujuće je koliko se u praksi koriste drugi pristupi (ovo ovde mogu lako popraviti, ovo mi deluje zanimljivo, ovo je sigurno problem jer se radi u petlji itd.).

Disciplinovana primena drugog principa često je osporila kako individualnu tako i kolektivnu intuiciju o tome gde je najbolje mesto za popravku performansi. Razlog je vrlo jednostavan. Evo i primera:

Pretpostavimo da imamo dve metode od kojih jedna (metoda A) troši 80% procesorskog vremena, a druga (metoda B) preostalih 20%. Zatim pretpostavimo da obe metode možemo ubrzati dvostruko, tj. skratiti vreme izvršavanja na pola. Ukoliko ubrzamo metodu B, skratićemo ukupno vreme izvršavanja sa faktorom 0,2 x 0,5 = 0,1, odnosno 10%. Ukoliko pak ubrzamo metodu A, skratićemo ukupno vreme izvršavanja sa faktorom 0,8 x 0,5 = 0,4, odnosno 40%, što je dvostruko više nego da potpuno izbacimo metodu B! Ma kako menjali odnose ovaj zaključak i dalje važi.

Disciplinovana primena ova dva pravila nam omogućava da performanse plaćamo minimalnom cenom i da za to dobijamo najveću vrednost.

Postoji mnogo metoda pomoću kojih možemo analizirati performanse programa. Od toga da u svoj kod ugradimo merenje vremena izvršavanja i da te rezultate ispisujemo, preko toga da koristimo performance counters (što možemo samo na Windows-u), do toga da koristimo razne eksterne alate da snimimo parametre izvršenja koje kasnije možemo analizirati (utrošak procesorskog vremena, memorije itd.). Svi ti pristupi imaju svoje prednosti i nedostatke i mogu biti najbolji način u određenim situacijama.

Jedan od tih alata je i PerfView, koji je besplatan i ne zahteva nikakvu posebnu instalaciju jer se sve nalazi u jednom izvršnom fajlu, a nudi mnogo mogućnosti za analizu performansi na Windows platformi. Ukoliko želite da vidite kako se PerfView koristi za analizu performansi .NET aplikacija pridružite mi se na PowerIT konferenciji gde ću pričati upravo o tome.

Online konferencija PowerIT u organizaciji razvojnog centra Schneider Electric održaće se od 22-23. septembra. Više o ovom događaju i agendi potražite na zvaničnom sajtu.