Na początku projektu nie zwraca się zbytniej uwagi na optymalizację kodu. Problem się zaczyna po pewnym czasie gdy do gry są dokładane coraz to nowe dane a kod staje się coraz bardziej złożony. W pewnym momencie można być nie mile zaskoczonym, że coś co w fazach testu było szybkie, teraz ślimaczy się doprowadzając do białej gorączki. Gdy 2fpsy i wczytywanie danych przez minute zaczynają coraz bardziej doskwierać wtedy warto pomyśleć o optymalizacji. Oczywiście odpowiednio napisany kod, projektowany od samego początku “z głową” nie będzie tak uciążliwy w późniejszym etapie, nie mniej jednak zawsze się okazuje, że coś można usprawnić (np. zrobić mniejszą uniwersalność niż zakładana na początku). Sporo osób uważa, że wręcz koniecznością jest używanie klas std, aby uzyskać spójny i elegancki kod. Tymczasem konstrukcja tych klas jest daleka od optymalnej i jak się może okazać, nie nadaje się do pisania zoptymalizowanych gier. Jedną z ciekawszych rzeczy na którą ostatnio natrafiłem było powolne wczytywanie danych spowodowane użyciem std::string. Z racji formatu danych, musieliśmy zapamiętywać oraz obrabiać duże ilości stringów i właśnie klasa std::string okazała się “wąskim gardłem”. Rozwiązaniem było użycie własnej klasy, która pozwoliła na przyśpieszenie wczytywania danych o ok. 30%, dzięki wyeliminowaniu dużej ilości alokacji pamięci.

Inną klasą, która może przysporzyć problemów jest jak się okazuje std::vector. std::vector posiada szybszy dostęp do danych niż np. std::list, czy std::map lecz problemem mogą się okazać zbyt częste alokacje danych, zwłaszcza jeśli się dzieje to w każdej ramce renderingu. Implementacja która się znajduje w VC7.1 zwiększa bufor za każdym razem o 50% to oznacza, że kolejne dodawanie 10 elementów do std::vector (za pomocą push_back() ) wymaga aż 7 (!!!) alokacji pamięci. Częściowym rozwiązaniem będzie np. wywołanie reserve(), lecz najlepszym rozwiązaniem jest użycie np. własnej klasy, która będzie alokować pamięć o stałej długości, np. w paczkach po 64 elementy. Możemy oczywiście podawać klasie wielkość takiej paczki o którą ma się zwiększać bufor.

Generalnie nigdy nie byłem zwolennikiem używania klas biblioteki standardowej głównie z powodu niewygodnego używania, ale teraz jestem im przeciwny również z tego powodu, że nie są przystosowane do pisania zoptymalizowanego kodu. W jednej z prezentacji ktoś z XBox Team pokazał, że użycie klas std, a zwłaszcza złe użycie klas std, może obciążyć CPU o dodatkowe 10% a to jest sporo. I jak całkiem trafnie to potem podsumował “Clearly, the std is EVIL”.

Optymalizacja cz.1. Biblioteka std.
0 votes, 0.00 avg. rating (0% score)