Optimering

Optimering

> LeekScript handledning

Här kommer vi att prata om optimering, målet med optimering är att förbättra prestandan hos en algoritm. I allmänhet, när vi talar om optimering, talar vi om exekveringstid, målet är att minska tiden som krävs för att exekvera en serie instruktioner.

I LeekScript uppskattas denna exekveringstid av ett tal: antalet operationer som används av denna beräkning. Vi kommer därför att prata om vissa goda rutiner och bra reflexer för att optimera ett program, oavsett språk, samt vissa optimeringar som är mer specifika för LeekScript, och intimt kopplade till det sätt på vilket operationer räknas.

Om du inte redan har gjort det, inbjuder jag dig att läsa LeekScript Tutorial-artikeln: Operations.

Bra reflexer

• Optimera inte innan du har en kod som fungerar: Det finns faktiskt en god chans att kodbiten som vi skriver bara kommer att anropas en gång per tur, vilket innebär att tiden som går åt till att optimera koden inte kommer att ha någon märkbar effekt på den totala förbrukningen av verksamheten.

Om du till exempel sparar 500 operationer på en funktion som bara anropas en gång sparar du bara 500 operationer. (logik) Å andra sidan kan en besparing av en enstaka operation, på en funktion som anropas i en loop of loop of loop, minska kostnaden vid operationer för flera tiotusentals operationer.

Vilket för mig till den andra punkten:

• identifiera var det är dyrt!

Halva arbetet med att optimera en kod består helt enkelt av att leta efter vart verksamheten går (då måste man skrika högt och säga åt dem att komma tillbaka). Vad är dyrt i koden?

För det, ingen hemlighet, vi kommer att mäta!

I vår arsenal tillhandahåller LeekScript en funktion som kommer att visa sig mycket användbar: getOperations. Den här funktionen gör det möjligt att veta hur många operationer som hittills använts i koden.

Exempel på ett enkelt verktyg för att mäta kostnaden för en funktion:

global __debug_operation; function startOp(){ __debug_operation = getOperations(); } function stopOp(title){ let ops = getOperations()-__debug_operation - 3; debug("Operationer (" + titel + "): " + ops); }

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

startOp(); say("hej världen"); stopOp("hej världen"); // hej världen: 30

Vi kan alltså bekräfta att säg kostar 30 operationer, som aviserats av dokumentationen.

Det är möjligt, och jag rekommenderar starkt att du gör verktyg för att mäta andra saker i din AI, som antalet anrop till en funktion, såväl som dess genomsnittliga kostnad till exempel, vilket bättre kommer att mäta kostnadsutvecklingen i din AI, och effekten av vissa optimeringar.

Sidan Komplexitet hjälper dig att förstå varför en algoritm är dyr och hur du löser problemet. För att sammanfatta väldigt enkelt så undviker vi helst häckande slingor mellan dem så långt det är möjligt. Vi kommer också att försöka begränsa storleken på våra loopar, till exempel genom att bara bläddra i våra tillgängliga celler istället för att bläddra i alla celler på kartan. Det är viktigt att notera att en algoritm som har lägre komplexitet kommer att använda mycket färre operationer för ett tillräckligt stort antal objekt att bearbeta, tänk på det innan du försöker repa små optimeringar!

Ta bort slingor som inte kommer att förändras

Föreställ dig följande kod:

låt TP = getTP();

// skjut så många gånger som möjligt på fienden! for (var i = 0; i < floor(TP / getWeaponCost(getWeapon())); i++) { useWeapon(getNearestEnemy()); }

Funktionen getNearestEnemy kommer att anropas vid varje iteration av loopen medan den alltid kommer att returnera samma resultat! För att undvika detta, sätt bara resultatet i en variabel före funktionen. Vi gör samma sak för floor(TP / getWeaponCost(getWeapon())) som också utvärderas vid varje iteration. Som ger:

låt TP = getTP();

// skjut så många gånger som möjligt på fienden! var enemy = getNearestEnemy(); var nbShots = floor(TP / getWeaponCost(getWeapon())); // antal möjliga skott med det aktuella vapnet för (var i = 0; i < nbShots; i++) { använd Vapen(fiende); }

Leek Wars-funktioner som är dyra

inArray, inArray är praktiskt, det gör vad vi vill, men det innebär en betydande kostnad i verksamheten som vi inte nödvändigtvis märker vid första anblicken. Faktum är att det ser ut så här inuti:

function inArray(element, array){ for (var-värde i array) if (värde == objekt) returnera sant; returnera falskt; }

Det här exemplet är en bra illustration för att prata om lite komplexitet. Vi ser här att den verkliga kostnaden för denna funktion i värsta fall beror på storleken på array-arrayen, som vi kommer att döpa till n*. Denna funktion har därför en komplexitet *n, det är den