Optimering

Optimering

> LeekScript vejledning

Her vil vi tale om optimering, målet med optimering er at forbedre ydeevnen af en algoritme. Generelt, når vi taler om optimering, taler vi om eksekveringstid, hvor målet er at reducere den tid, der kræves for at udføre en række instruktioner.

I LeekScript estimeres denne udførelsestid af et tal: antallet af operationer, der bruges af denne beregning. Vi vil derfor tale om visse god praksis og gode reflekser til at optimere et program, uanset sproget, samt visse optimeringer, der er mere specifikke for LeekScript, og som er tæt knyttet til den måde, hvorpå operationer tælles.

Hvis du ikke allerede har gjort det, inviterer jeg dig til at læse LeekScript Tutorial-artiklen: Operations.

Gode reflekser

• Optimer ikke, før du har en kode, der virker: Der er faktisk en god chance for, at det kodestykke, vi skriver, kun bliver kaldt én gang pr. tur, hvilket betyder, at den tid, der bruges på at optimere koden, ikke vil have nogen mærkbar effekt på det samlede forbrug af driften.

For eksempel gemmer 500 operationer på en funktion, der kun kaldes én gang, kun 500 operationer. (logik) På den anden side kan en besparelse af en enkelt operation på en funktion, der kaldes i en sløjfe af sløjfe af sløjfe, reducere omkostningerne ved operationer af flere titusindvis af operationer.

Hvilket bringer mig til det andet punkt:

• identificer hvor det er dyrt!

Halvdelen af arbejdet med at optimere en kode består blot i at lede efter, hvor operationerne går (så skal du råbe højt og bede dem komme tilbage). Hvad er dyrt i koden?

For det, ingen hemmelighed, vil vi måle!

I vores arsenal giver LeekScript en funktion, der vil vise sig at være meget nyttig: getOperations. Denne funktion gør det muligt at kende antallet af operationer brugt indtil nu i koden.

Eksempel på et simpelt værktøj til at måle omkostningerne ved en funktion:

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

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

startOp(); sige("hej verden"); stopOp("hej verden"); // hej verden: 30

Vi kan således bekræfte, at sige koster 30 operationer, som meddelt i dokumentationen.

Det er muligt, og jeg anbefaler stærkt, at du laver værktøjer til at måle andre ting i din AI, som antallet af kald til en funktion, såvel som dens gennemsnitlige omkostninger for eksempel, hvilket bedre vil måle udviklingen af omkostninger i din AI, og virkningen af visse optimeringer.

Siden Kompleksitet hjælper dig med at forstå, hvorfor en algoritme er dyr, og hvordan du løser problemet. For at opsummere meget enkelt, foretrækker vi så vidt muligt at undgå indlejrede løkker mellem dem. Vi vil også søge at begrænse størrelsen af vores sløjfer, for eksempel ved kun at gennemse vores tilgængelige celler i stedet for at gennemse alle cellerne på kortet. Det er vigtigt at bemærke, at en algoritme, der har lavere kompleksitet, vil bruge meget færre operationer til et stort nok antal elementer til at behandle, tænk over det, før du prøver at ridse små optimeringer!

Fjernelse af løkker, som ikke vil ændre sig

Forestil dig følgende kode:

lad TP = getTP();

// skyd så mange gange som muligt på fjenden! for (var i = 0; i < floor(TP / getWeaponCost(getWeapon())); i++) { useWeapon(getNearestEnemy()); }

getNearestEnemy-funktionen vil blive kaldt ved hver iteration af løkken, mens den altid vil returnere det samme resultat! For at undgå dette skal du blot sætte resultatet i en variabel før funktionen. Vi gør det samme for floor(TP / getWeaponCost(getWeapon())) som også evalueres ved hver iteration. Som giver:

lad TP = getTP();

// skyd så mange gange som muligt på fjenden! var enemy = getNearestEnemy(); var nbShots = floor(TP / getWeaponCost(getWeapon())); // antal mulige skud med det aktuelle våben for (var i = 0; i < nbShots; i++) { brug Våben(fjende); }

Leek Wars-funktioner, der er dyre

inArray, inArray er praktisk, det gør, hvad vi vil, men det medfører en betydelig omkostning i operationer, som vi ikke nødvendigvis bemærker ved første øjekast. Faktisk ser det sådan ud indeni:

function inArray(element, array){ for (var-værdi i matrix) if (værdi == vare) returnere sandt; returnere falsk; }

Dette eksempel er en god illustration til at tale om lidt kompleksitet. Vi ser her, at de reelle omkostninger ved denne funktion i værste fald afhænger af størrelsen af array-arrayet, som vi vil navngive n*. Denne funktion har derfor en kompleksitet *n, det er