On Sun, 17 May 2009 02:31:27 -0700 (PDT), Marteno Rodia
<m...@o...pl> wrote:

>Góglałem, ale nie udało mi się znaleźć syntetycznej odpowiedzi na
>pytanie. Interesuje mnie, jak należy pisać program, żeby wykonywał się
>on szybko. Z reguły pisuję w Javie, teraz mam napisać program (a
>właściwie część do większego programu) w C++, który wykonuje pewne
>obliczenia potrzebne do kompresji wideo. Będzie dużo danych i dużo
>liczenia.
>
>Ogólnie wiem, że:
>
>1) dużo czasu zjadają np. operacje wejścia/wyjścia
>2) w miarę możliwości warto przydzielać pamięć statycznie, a nie
>dynamicznie
>3) unikać nadmiaru rzeczy wykonywanych w pętli (np. sprawdzanie
>jakichś warunków) - innymi słowy:
>4) tak przebudować algorytm, żeby zrobić to samo wykonując mniejszą
>ilość operacji.
>
>Pytania:
>1) Czy mam rację?
>2) Co jeszcze o czym nie wiem?

Nei wiesz o Zadadach Kernighana:

1. "Make it working frst, make it nice later". Najpierw program musi
dzialac, a POTEM musi dzialac szybko. Optymalizacja w trakcie pisania
programu da architektoniczny potworek, na ogol i tak daleki od
optymalnosci. Oczywiscie, nie nalezy uzywac rozwiazan o ktorych od
razu wiadomo ze sa neidobre, na przykald liczenei w kolko tego samego
wyrazenia w petli, czy stosowanei niewlasciwych struktur danych

2. "20% kodu pochlamie 80% casu wykonywania programu". Tzreba te 20%
znalezc i zoptymalizowac. Oczywiscie, po zoptymalizowaniu, INNE 20%
czasu bedzie pochlanialo 80%, wiec procedura musi byc stosowana
iteracyjnie

3. Stosowac nalezy odpowiednei struktury danych zapewniajace
odpowienia zlozonosc obliczeniowa stosowna do skali problemu. Lista
jest bardzo pomocna struktura, ale wyszukwianei w liscie jest liniowe
i kosztowne. Wiec jak lisyta jest dluga a wyszukwianie czeste, to
uzywanei listy bedzie powodowalo starte czasu.

Lista to tylko przyklad. Ilu programistow w Javie uzywajacych HashMap
wie co to jest "loading factor" i dlaczego HasnMap ma konstruktor
pozwalajacy zdefiniowac ow "loading factor"?...

Dla programistow w Jave polecam ksiazke "Java Performance Tuning",
Jack Shirazi, O'Reilly, 2000

A.L.