niemodna optymalizacja

Tempo postępu technologicznego w informatyce jest (przynajmniej dla mnie) jednym z największych zaskoczeń ostatnich dziesięcioleci. Moc obliczeniowa komputerów wzrasta tak szybko, że nieraz jest to "poniżej ludzkiej godności", jak zwykł mawiać mój kolega. Znaczenie określenia "dobry sprzęt" zmienia się błyskawicznie i wyobrażam sobie, że ludzie chcący za tym nadążyć nie zajmują się niczym więcej. Niestety wraz ze sprzętem dewaluuje się pojęcie "dobrego" oprogramowania. Przyzwyczajeni do szybkich i tanich komputerów przestajemy zwracać uwagę na takie szczegóły jak optymalizacja kodu, wykorzystania pamięci czy szybkości obliczeń. Problemy z wydajnością oprogramowania nagminnie rozwiązuje się bezczelnie prostym stwierdzeniem — "poda się w specyfikacji większą ilość wymaganej pamięci, to kosztuje grosze". I niestety to jest prawda, co tylko umacnia trend ignorowania pojęcia optymalizacji. Jednak paradoksalnie rozczarowanie przychodzi w momencie kiedy zechce się napisać coś "naprawdę zgodnego z trendami", ponieważ "trendy" to dzisiaj urządzenia mobilne.

Pisząc oprogramowania na urządzenia klasy PDA musimy się zmierzyć z rzeczywistością procesorów do 400MHz i pamięci RAM rzędu 64MB! I to w tych nowszych/droższych, bo modele z procesorami 266MHz i pamięcią 32MB są wciąż reklamowane jako affordable. Komputer biurkowy o takich parametrach byłby uznany za staroć — dobry najwyżej do szkoły na wstępny kurs informatyki albo do biura jako maszyna do pisania, ale na pewno nie jako komputer spełniający wymagania sprzętowe "nowoczesnego" systemu[1]. Dla programisty rozpuszczonego na dobrych-dziś-lepszych-jutro komputerach stacjonarnych oprogramowanie PDA to bolesny powrót do przeszłości.

Nagle trzeba sobie przypomnieć na wpół zapomniane teorie, mówiące o tym, że być może sposób napisania kodu ma wpływ na szybkość wykonania i zużycie pamięci. Być może napisanie czegoś lepiej zaoszczędzi więcej niż zaniedbywalne 2/100 sekundy. Być może kilkanaście niepotrzebnie zaalokowanych kilobajtów pomnożone przez ilość miejsc z komentarzem /* mała strata, olewam */ spowoduje jednak zauważalne zwiększenie zużycia zasobów. Niby wszyscy to wiedzą, niby "dobry programista zawsze dobrze pisze", ale jednak ignorancja postępuje (tak to zwykle bywa z wiedzą zbyt powszechną). Oczywiście znaczny udział w powstaniu takiej sytuacji mają wymagające środowiska typu Java czy .NET, które i tak muszą uruchomić swoje maszyny wirtualne czy inne frameworki. Ich zakamarków większość programistów nie zna i znać nie chce, przyjmując bez sprzeciwu założenie, że "się musi dużo załadować" i "się muli na słabym sprzęcie". Tak po prostu. Jednak wymagające środowisko to jedno, a marnotrawstwo w najmniejszych, najbardziej banalnych szczegółach to coś całkiem innego.

Szybka inspekcja kodu jednego z naszych projektów wykazuje najróżniejsze kwiatki np. w takim stylu:

string query = "select * from T_POST"
             + "where T_POST.UserID = @UserID "
             + "and T_POST.Text like '%@Search%'";

Wartość query jest tutaj sklejona z trzech tekstów, tylko dlatego, żeby kod wyglądał "ładnie" i "równo"... A kto pomyślał o ilości tworzonych w tej jednej linii obiektów i wywoływanych operatorów? Kto pomyślał ile na to trzeba pamięci i ile niepotrzebnej roboty będzie miał garbage collector? Jakoś nikt... Bo przecież moc obliczeniową się dokupuje za grosze, a programowanie z myślą, że wydajność ma znaczenie jest ostatnio zupełnie niemodne. :-/

Jako puenta — cytat z dzisiejszej dyskusji na podobne tematy:

— "najlepszy team programistyczny w południowej Polsce" dyskutuje o sklejaniu stringów...
— tak, to żałosne.

[1] Chyba nikt przy zdrowych zmysłach nie wierzy w to, że np. taki Windows XP "pójdzie" na 233MHz z 64MB pamięci RAM...

2004.05.21 | 7 komentarzy | RDF

tagi »

Komentarze

#1 | 2004.05.21 20:20 | Shot

Oczywiście znaczny udział w powstaniu takiej sytuacji mają wymagające środowiska typu Java czy .NET, które i tak muszą uruchomić swoje maszyny wirtualne czy inne frameworki. Ich zakamarków większość programistów nie zna i znać nie chce, przyjmując bez sprzeciwu założenie, że „się musi dużo załadować” i „się muli na słabym sprzęcie”.

Daj spokój, oglądam sobie właśnie ostatnio jak na Marty sprzęcie (Celeron 400 MHz, 288 MiB pamięci) działa iRATE, i nie mogę za cholerę zrozumieć, czemu tak zgrabną aplikację napisano w tak cholernie zasobożerny sposób. :o|

#2 | 2004.05.23 10:13 | MiMaS

Przez "daj spokój" chcesz powiedzieć "gadasz głupoty" czy "wiem coś o tym"?

Problem z programami tego typu (klientami do sieci/usług najróżniejszych) polega na założeniu ich maksymalnej uniwersalności i niezależności od systemu użytkownika. Wybór w sposób dosyć oczywisty pada na Javę (choć może nie długo — mono rośnie w siłę), a Java jak wiadomo ma swoje wymagania i kaprysy. W takiej sytuacji optymalizacja rozwiązania polega bardziej na wyborze platformy, niż na samym "dobrym kodowaniu" — to decyzja biznesowa...

#3 | 2004.05.23 11:52 | Shot

„Daj spokój” w sensie „wiem coś o tym”.
Co do uniwersalności – rozumiem, że tym podyktowany był wybór języka (tzn. mam nadzieję, że nie faktem, że autor „Javę umie”, a inszych nie bardzo), ale jednak w przypadku iRATE-a moim zdaniem zdecydowanie więcej sensu miałby szybki klient commandline’owy (dajmy na to w Pythonie) plus osobne GUI (niech sobie będzie w czymkolwiek, w razie czego zawsze możnaby napisać drugie, szybsze/mniej przenośne).
Oczywiście pytanie brzmi, jak dużo straciłoby się na uniwersalności – nie wiem, czy do Pythona też są takie sprytne rzeczy jak gcj, może nie ma – a jak dużo zyskałoby się na szybkości/wygodzie użytkowania (i wśród jak dużej grupy użytkowników); pewnie też nie powinienem marudzić, tylko jeśli mi się nie podoba, to usiąść i samemu pyRATE-a napisać… ;o)

#4 | 2004.05.23 18:51 | MiMaS

Jasne, "więcej sensu miałby"... Tylko IMHO w praktyce to jest tak, że nikt nie używa "szybkiego klienta commandline’owego" tylko programu z jakimś cywilizowanym GUI, napisanego najczęściej .... w Javie właśnie. Dokładnie tak jest w przypadku BitTorrenta na przykład ;-)

#5 | 2004.05.23 21:46 | Shot

Nikt jak nikt – ja sobie bardzo cenię, że mogę będąc w Łodzi czytać maile na kompie w Warszawie (mutt), rozmawiać przez Gadu-Gadu mając historę rozmów w jednym miejscu (ekg), sterować mldonkeyem (m. in. klient BitTorrenta właśnie) gdy właśnie najbardziej się przydaje, bo i tak łącza prawie nie używam… I tak się składa, że wszystkie te programy mają UI na tyle cywilizowane, że wracając do domu nie przesiadam się na graficzne odpowiedniki.
Jasne, że w przypadku iRATE akurat zdalna praca sensu zbytnio nie ma, ale jakoś już się przyzwyczaiłem, że ciężki, graficzny klient w Javie to rzadko kiedy jedyne rozwiązanie – przypadek kompa Marty dowodzi, że na dodatek niekoniecznie tak uniwersalne, jakby to wyglądało w teorii (jestem święcie przekonany, że gdyby taki xmms był tylko w Javie, to zostałby do czegoś „szybszego” przepisany w try miga). :o)

#6 | 2004.05.23 22:51 | MiMaS

Trudno powiedzieć, żeby mutt czy ekg to były narzędzia "szybkie comandline'owe". ;-) Szybkie owszem i tekstowe owszem, ale jednak "wypasione". Zresztą dawanie za przykład takich narzędzi, albo takiego usera jak Ty raczej mija się z celem — wybacz, ale jedno i drugie to margines. "Hajendowy" ale jednak margines...

Natomiast program z rozbudowanym GUI (ku zadowoleniu szerokiej publiczności) napisany w Javie (ku zadowoleniu działu marketingu) jeszcze długo będzie znajdował większe grono odbiorców. Dlatego umiejętność napisania kodu tak, aby mimo Javy i wszystkiego co się musi, program działał znośnie nawet na wczorajszym sprzęcie jest sztuką godną pochwały.

#7 | 2004.05.24 00:20 | margines

Co do wypasienia, to może tu jest pies pogrzebany – o ile jeszcze mogę zrozumieć pisanie GUI do BitTorrenta w Javie, to jednak klient iRATE-a, przynajmniej w takiej postaci w jakiej jest teraz, jak dla mnie javowego bloatu nie uzasadnia. Nie mam nic przeciwko temu, żeby w Javie był sam interfejs graficzny, ale może niekoniecznie chciałbym, żeby był to jedyny słuszny sposób „dostania się” do funkcjonalności aplikacji. Wiem, wiem, powinienem sobie sam to napisać…

A co do zadowalania szerokiej publiczności – cóż, wolałbym, żeby zadowalano mnie, a nie ją. :o) Szczególnie, że ta szeroka publiczność ma, jak słusznie zauważasz, niedługo używać całkiem sporej ilości sprzętu low-end (PDA chociażby). Zresztą o ile dominację mutta na linux-elitists można nadal uzasadniać „hajendowym marginesem”, o tyle już jego spory udział wśród ludzi piszących na taką debian-user sugeruje, że może ten margines jest wystarczająco szeroki, żeby brać go pod uwagę… ;o)

 

Uwaga: Ze względu na bardzo intensywną działalność spambotów komentowanie zostało wyłączone po 60 dniach od opublikowania wpisu. Jeżeli faktycznie chcesz jeszcze skomentować skorzystaj ze strony kontaktowej.