Optymalizacja

Optymalizacja

> LeekScript samouczek

Tutaj porozmawiamy o optymalizacji, celem optymalizacji jest poprawa wydajności algorytmu. Ogólnie rzecz biorąc, kiedy mówimy o optymalizacji, mówimy o czasie wykonania, którego celem jest skrócenie czasu potrzebnego do wykonania serii instrukcji.

W LeekScript ten czas wykonania jest szacowany przez liczbę: liczbę operacji użytych w tym obliczeniu. Dlatego będziemy mówić o pewnych dobrych praktykach i dobrych odruchach optymalizacji programu, niezależnie od języka, a także o pewnych optymalizacjach bardziej specyficznych dla LeekScript i ściśle związanych ze sposobem liczenia operacji.

Jeśli jeszcze tego nie zrobiłeś, zapraszam do przeczytania artykułu LeekScript Tutorial: Operations.

Dobry refleks

• Nie optymalizuj, zanim kod nie będzie działał: istnieje duże prawdopodobieństwo, że napisany przez nas fragment kodu zostanie wywołany tylko raz na turę, co oznacza, że czas poświęcony na optymalizację kodu nie będzie miał zauważalnego wpływu na ogólne zużycie operacji.

Na przykład zapisanie 500 operacji na funkcji wywołanej tylko raz spowoduje zapisanie tylko 500 operacji. (logika) Z drugiej strony, oszczędność pojedynczej operacji, na funkcji wywoływanej w pętli pętli pętli, może obniżyć koszt operacji o kilkadziesiąt tysięcy operacji.

Co prowadzi mnie do drugiego punktu:

• określ, gdzie jest drogo!

Połowa pracy związanej z optymalizacją kodu polega po prostu na szukaniu, gdzie kończą się operacje (wtedy trzeba głośno krzyczeć i kazać im wrócić). Co jest drogie w kodzie?

W tym celu, bez tajemnic, zmierzymy!

W naszym arsenale LeekScript udostępnia funkcję, która okaże się bardzo przydatna: getOperations. Ta funkcja pozwala poznać liczbę operacji wykonanych do tej pory w kodzie.

Przykład prostego narzędzia do pomiaru kosztu funkcji:

globalna operacja __debugowania; funkcja startOp(){ __debug_operation = getOperations(); } funkcja stopOp(tytuł){ niech ops = getOperations()-__debug_operation - 3; debug("Operacje (" + tytuł + "): " + ops); }

startOp(); stopOp("pusty test"); // pusty test: 0

startOp(); powiedz("witaj świecie"); stopOp("Witaj świecie"); // witaj świecie: 30

Możemy więc potwierdzić, że powiedzmy kosztuje 30 operacji, jak zapowiada dokumentacja.

Jest to możliwe i zdecydowanie zalecam, abyś stworzył narzędzia do mierzenia innych rzeczy w twojej AI, takich jak liczba wywołań funkcji, a także na przykład jej średni koszt, który lepiej zmierzy ewolucję kosztów w twojej AI, oraz wpływ niektórych optymalizacji.

Strona Złożoność pomoże Ci zrozumieć, dlaczego algorytm jest drogi i jak rozwiązać problem. Podsumowując bardzo prosto, wolimy w miarę możliwości unikać zagnieżdżania pętli między nimi. Będziemy również dążyć do ograniczenia rozmiaru naszych pętli, na przykład przeglądając tylko nasze dostępne komórki zamiast przeglądać wszystkie komórki mapy. Ważne jest, aby pamiętać, że algorytm o mniejszej złożoności użyje dużo mniej operacji dla wystarczająco dużej liczby elementów do przetworzenia, pomyśl o tym, zanim spróbujesz zdrapać małe optymalizacje!

Usuwanie pętli, które się nie zmienią

Wyobraź sobie następujący kod:

niech TP = pobierzTP();

// strzelaj jak najwięcej razy we wroga! for (var i = 0; i < floor(TP / getWeaponCost(getWeapon())); i++) { useWeapon(getNearestEnemy()); }

Funkcja getNearestEnemy będzie wywoływana przy każdej iteracji pętli, podczas gdy zawsze zwraca ten sam wynik! Aby tego uniknąć, wystarczy umieścić wynik w zmiennej przed funkcją. Robimy to samo dla floor(TP / getWeaponCost(getWeapon())), które jest również oceniane w każdej iteracji. Które dają:

niech TP = pobierzTP();

// strzelaj jak najwięcej razy we wroga! var wróg = pobierz najbliższego wroga(); var nbShots = floor(TP / getWeaponCost(getWeapon())); // liczba możliwych strzałów z aktualnej broni for (var i = 0; i < nbShots; i++) { użyjBroń(wróg); }

Funkcje Leek Wars, które są drogie

inArray, inArray jest praktyczne, robi to, co chcemy, ale wiąże się ze sporym kosztem operacji, którego niekoniecznie zauważamy na pierwszy rzut oka. W rzeczywistości w środku wygląda to tak:

funkcja inArray(element, tablica){ for (wartość var w tablicy) jeśli (wartość == element) zwróć prawdę; zwróć fałsz; }

Ten przykład jest dobrą ilustracją, aby porozmawiać o odrobinie złożoności. Widzimy tutaj, że rzeczywisty koszt tej funkcji zależy w najgorszym przypadku od rozmiaru tablicy tablicowej, którą nazwiemy n*. Ta funkcja ma zatem złożoność *n