156

Kto powiedział, że wielkość nie ma znaczenia? Jeśli chodzi o wydajność, to na pewno ma. Im kod jest większy, tym z reguły jest wolniejszy. Jest to szczególnie zauważalne w wypadku nowego oprogramowania dla procesorów Pentium, w którym jest ograniczona pamięć podręczna. Koszt wyszukiwania kodu i danych w pamięci podręcznej pozwala zauważyć różnicę między działaniem szybkim a działaniem wolnym. Jeśli dane lub kod nie są umieszczone w głównej lub pomocniczej pamięci podręcznej, to procesor musi je pobrać z pamięci operacyjnej. Oznacza to, że więcej cykli procesora zajmie pobieranie instrukcji niż ich wykonywanie. W tym rozdziale zawarto wiele wskazówek przydatnych przy poprawianiu wydajności kodu.

113

Projekt jest ważniejszy od późniejszego dopracowywania kodu

rada

Nie ważne jak doskonale potrafimy „dopieścić” kod w celu uzyskania największej wydajności — i tak nie możemy sprawić, że zły projekt zadziała szybko. Używanie lepszych struktur danych i algorytmów da nam znacznie większą wydajność, niż jakiekolwiek dostrajanie kodu. Na przykład systemy plików komputerów osobistych przechowywały kiedyś nazwy katalogów w tablicy. Znajdowanie odpowiedniego pliku oznaczało liniowe przeszukiwanie listy. Im więcej plików było w katalogu, tym dostęp do nich był wolniejszy. Poprawianie kodu przeszukującego nie miało szans konkurować ze zmianą struktury na B-drzewo. Dzięki nowej strukturze dostęp do plików stał się o wiele szybszy.

Należy przewidzieć użycie programu przez typowego klienta. Należy zrozumieć granice problemu. Należy głęboko się zastanowić nad podjętym rozwiązaniem i poczynionymi założeniami. Następnie należy pomyśleć o lepszym podejściu. Poddać w wątpliwość nasze rozwiązanie. Czy na pewno musimy zastosować odzyskiwanie pamięci. Czy do wszystkiego jest nam potrzebna obsługa transakcji? Czy ostatecznie nie uzyskaliśmy więcej danych, niż się spodziewaliśmy, i tracimy czas na ich przeszukiwaniu? Czy zaprojektowaliśmy program z myślą o wielkich zbiorach danych, ale w rzeczywistości dane nie są tak obszerne i lepsze będzie jakieś prostsze rozwiązanie?

Autorzy pracowali kiedyś nad językiem zapytań, który miał polecenie do znajdowania w bazie danych «-tego rekordu o podanych kryteriach. Okazało się, że najczęstsze zapytania dotyczyły pierwszego i ostatniego rekordu. Zmieniając struktury i tworząc oddzielne kody dla tych dwóch przypadków, udało się uzyskać nieprawdopodobny wzrost szybkości.

Często znacznie łatwiej przyspieszyć nieskomplikowane rozwiązania, gdyż są bardziej zrozumiałe i łatwiej je zmieniać.