Kiedy najlepiej rozważyć wydajność?

Pochodzę ze środowiska programistycznego. Podczas cyklu tworzenia oprogramowania zwykle koncentrujemy się na funkcjonalnościach i działającym produkcie. Pod koniec programowania zaczynamy optymalizować kod i zwiększać wydajność.

Teraz pytanie brzmi: czy musimy myśleć o wydajności w każdym wierszu kodu przy tworzeniu gier?

W ten sposób czuję, że brakuje nam wzorów i czystego kodu. Zastanawiałem się, czy istnieje jakakolwiek najlepsza praktyka w branży tworzenia gier?

Inżynieria wydajności

• Postępuj zgodnie z zaleceniami dostawcy.
• Użyj poprawnych struktur danych.
• Zaimplementuj prawidłowe wzorce użytkowania.
• Nie rób nic głupiego.

Optymalizacja

• Gdy już napisany kod działa wolno, zmierz go, dowiedz się, dlaczego, a następnie zaimplementuj to, co jest potrzebne, aby było szybkie.

Przedwczesna optymalizacja

• Dokonuj założeń dotyczących tego, co jest szybkie lub wolne bez pomiarów, zbuduj te założenia w sposobie projektowania i pisania kodu.

Te trzy rzeczy nie są takie same .

W szczególności Inżynieria wydajności jest czymś, co powinieneś robić od samego początku i zdecydowanie nie jest tym samym co Optymalizacja przedwczesna, ponieważ opiera się na rzeczywistych pomiarach; w tym przypadku opierając się na doświadczeniu i zaleceniach, jak działa sprzęt i jakie wzorce użytkowania będą szybkie lub wolne.

Niezaprojektowanie pod kątem wydajności może prowadzić do tak złych wyników, jak konieczność całkowitego przeprojektowania i przepisania, zanim zauważysz, że coś jest nie tak.

Na przykład: wszyscy dostawcy GPU radzą, aby odczytywanie GPU z każdej ramki odbywało się powoli. Zaprojektowanie kodu w taki sposób, aby nie powodowało powtórzeń, nie jest przedwczesną optymalizacją .

Jeśli chcesz przeprowadzić optymalizację we właściwym czasie, miej wolne maszyny i korzystaj z nich. W przypadku małego sklepu dobrym rozwiązaniem jest użycie powolnego laptopa w drodze do pracy i szybkiego pulpitu w biurze. Dodatkową korzyścią jest to, że jeśli prowadzisz jednoosobowy sklep, zmusza cię to do właściwego wykonania kopii zapasowej całego środowiska kompilacji.

Używając wolnej maszyny, będziesz wiedział, kiedy potrzebujesz poprawić wydajność.

czy musimy myśleć o wydajności w każdym wierszu kodu podczas tworzenia gier?

Absolutnie nie. Wydajność wiersza kodu jest zwykle nieistotna w jakimkolwiek rozwoju. Musisz myśleć w kategoriach algorytmów i złożoności algorytmicznej , a nie w kategoriach linii. W wielu przypadkach przyzwoite programowanie oznacza, że ​​możesz uzyskać około 2-krotne przyspieszenie poprzez optymalizację linii kodu, ale wybór właściwego lub złego algorytmu spowoduje czynniki od dziesiątek do milionów.

Mówienie o przedwczesnej optymalizacji nie polega na tym, że optymalizacja jest złą rzeczą. Chodzi o ludzi, którzy nie optymalizują właściwej rzeczy. Twój czas jest jedną ze zmiennych, które należy zoptymalizować, co osiąga się przez nie marnowanie czasu na „optymalizację” funkcji, która jest wywoływana raz na 30 milisekund, a jej wykonanie zajmuje 100 mikrosekund.

Innymi słowy: tworzenie czegoś „szybciej” nie ma sensu. Twoim celem jest „wystarczająco szybko”. Robienie czegoś „szybszego”, co jest już „wystarczająco szybkie”, to strata czasu, a robienie czegoś „szybszego”, co wciąż nie jest „wystarczająco szybkie”, oznacza po prostu, że jest zbyt wolne. „szybszy” nie ma znaczenia, istotny jest tylko „wystarczająco szybki”.

Nie, nie musisz sprawdzać po każdej linii, ponieważ nie każda linia ma związek z wydajnością. Zależy to głównie od częstotliwości wykonywania linii. Sekcja kodu, której wykonanie zajmuje 1 ms, jest całkowicie nieistotna, gdy jest wykonywana raz podczas uruchamiania gry, warta obejrzenia przy wykonywaniu każdej klatki i musi być zdecydowanie zoptymalizowana, jeśli zostanie wykonana dla każdego obiektu gry w każdej klatce.

Zależy to również od rodzaju tworzonej gry. Tworząc bardzo intensywną graficznie strzelankę 3D, musisz być bardziej świadomy wydajności niż podczas programowania gry RPG w stylu retro.

Ostatecznie najlepszą radą jest test, test, test. Zbuduj realistyczne sceny testowe dla swojej gry, które wyświetlają na ekranie nieco więcej rzeczy, niż można by się spodziewać w prawdziwej grze. Przetestuj na sprzęcie, który znajduje się w dolnej części docelowych specyfikacji. Upewnij się, że wydajność jest zgodna z oczekiwaniami. Gdy sytuacja się pogorszy, użyj profilera, aby znaleźć wąskie gardła.

Musisz włożyć wystarczająco dużo wysiłku, aby przynajmniej przejść „czy to będzie potencjalnie wąskie gardło, a jeśli tak, to jak zaangażowana będzie zmiana, aby to naprawić?”.

Ogólnie rzecz biorąc, wiąże się to z równowagą między czasem / zasobami spędzonymi na ustalaniu, czy coś jest właściwym kierunkiem, a czasem / zasobami spędzonymi na podejmowaniu złych decyzji.

Pomyśl o tym trochę jak o remoncie mieszkania. Niektóre decyzje mogą mieć trwałe konsekwencje („Ups, lodówka nie mieści się już w jej kąciku.” „Ups, w którym chcę postawić swoją łazienkę nie ma wody”), ale nie pomyślisz o tym, jak każde pociągnięcie pędzlem może wpływać np. na stabilność konstrukcyjną budynku.

Lub, inaczej mówiąc, nie cofaj się w kąt. Lub przynajmniej wiedz, kiedy cofasz się w kąt i upewnij się, że jest to róg, w którym chcesz wrócić. Na przykład:

• Czy wiążę szybkość aktualizacji gry z graficzną szybkością klatek?
• Czy wymuszam synchroniczne zapisywanie?
• Czy wymuszam (nie) determinizm?

W grze Twoim głównym celem jest osiągnięcie docelowej prędkości klatek na docelowej maszynie o minimalnej specyfikacji (i ewentualnie maksymalnym czasie ładowania itp.).

Aby to zrobić, nie musisz się martwić po każdej linii.

Musisz martwić się wcześniej, ilekroć wybierzesz określoną strategię, algorytm lub kontener. Jeśli dosłownie uniemożliwisz osiągnięcie celu poprzez podejmowanie niewłaściwych decyzji projektowych, wówczas jakakolwiek optymalizacja, którą możesz zrobić później, nie przyniesie rezultatu.

Następnie musisz się martwić, gdy coś jest równoległe lub równoległe. Gry są masowo równoległe, jeśli nie bez innego powodu, to dlatego, że grafika jest.
Dlatego równoległe oznacza nie tylko „wątki”, ale także na przykład graficzny interfejs API, dostęp do dysku lub sieć. Ilekroć tracisz szansę posiadania czegoś, co można łatwo i natywnie równolegle uruchomić równolegle, na przykład z powodu złej synchronizacji (lub w ogóle z powodu niestosowania asynchronicznego interfejsu API), tracisz więcej niż kiedykolwiek możesz zoptymalizować za pomocą innych środków.
Musisz się również martwić, gdy coś się pojawijest dobrze znany jako wąskie gardło lub źródło kramów lub przeszkodę w osadzaniu się kamienia. Takich jak na przykład przełączanie stanów renderowania, rysowanie połączeń, odczytywanie z GPU lub otwieranie plików.

Na koniec, gdy skończysz, a testy wykażą, że nie osiągasz docelowej liczby klatek, musisz zoptymalizować. Znajdź jedno największe wąskie gardło, które zajmuje 90% czasu, i zoptymalizuj to. Jeśli to nie wystarczy, znajdź sekundy największe.
Jeśli osiągniesz cel, gratulacje. Idź dalej i zapomnij o tym.

Zejdź na ziemię. Odpowiedź jest po prostu całkowicie NIE. Bez dyskusji.

Głównym problemem jest sposób, w jaki pytasz:

czy musimy myśleć o wydajności w każdym wierszu kodu podczas tworzenia gier?

Masz na myśli również takie rzeczy jak ekrany konfiguracji? Jak jednorazowy parser dla małego pliku konfiguracyjnego o maksymalnej wielkości 1kb? Poważnie?

Nie ma znaczenia, jak ważna jest większość czasu w twoim kodzie. Nie ma jednego oprogramowania, w którym każda linia ma krytyczne znaczenie dla czasu. Nigdzie.