Revision as of 15:30, 10 May 2018

ⓘ

This page is an intended replacement for Code Optimisation. It is obviously a WORK-IN-PROGRESS.

Code Optimisation

Introduction

This article will try to be a general guide about improving your code and its performance.

The first part (Rules) will focus on having a clean, readable and maintainable code.
The second part (Code optimisation) is about improving performance, sometimes trading it against code readability.
The third part (Equivalent commands performance) mentions commands that in appearance have identical effects but may differ in terms of performance according to the use you may have of them.
The fourth part (Conversion from earlier versions) is a hopefully helpful, short guide about useful new commands or syntaxes to replace the old ways.

Rules

In the domain of development, any rule is a rule of thumb. If a rule states for example that it is better that a line of code doesn't go over 80 characters, it doesn't mean that any line must not go over 80 characters; sometimes, the situation needs it. If you have a good structure, do not change your code to enforce a single arbitrary rule. If you break many of them, you may have to change something. Again, this is according to your judgement.

With that being said, here are the three basic rules to get yourself in the clear:

Make it work
Make it readable
Optimise then

Make it work

Template:note Your first goal when coding is to make your code do what you want it does. A good way to reach this objective is to read and getting inspired by other people's code. If you understand it by reading it once, it is probably a good source of inspiration.

When starting from scratch if you know what you want but miss the specific steps to get to your point, it is a good practice to write down in your native language what you want to do. E.g Get all the units near the city, and for each west soldier in them, add 30% damage.
Use -showScriptErrors startup parameter and make sure your code doesn't throw errors. Not only will your code run slower but it may also not work at all. Be sure to read the error, isolate the issue and sort it out thanks to this Wiki.
Read your Arma RPT (report) to read more details about the error that happened in your code.

Make it readable

Whether you are cleaning your code or a different person's, you must understand the code without twisting your brain:

While SQF is (non-noticeably) impacted by variable name length, this should not take precedence on the fact that code must be readable by a human being. Variables like _u instead of _uniform should not be present.
One-lining (putting everything in one statement) memory improvement is most of the time not worth the headache it gives when trying to read it. Don't overuse it.
Indentation is important for the human mind, and space is too. Space is free, use it.
Same goes for line return; it helps to see a code block wrapping multiple common instructions instead of having to guess where it starts and stops.
Do you see the same code multiple times, only with different parameters? Now is the time to write a function!
If you have a lot of if..else, you may want to look at a switch condition, or again break your code in smaller functions.
Is your function code far too long? Break it in understandable-sized bites for your own sanity.
Finally, camel-casing (namingLikeThis) your variables and commands will naturally make the code more readable, especially for long names.

ⓘ

_i is an accepted variable standard for a for..do iteration

See the following code:

_w=[]; {_w pushbackunique primaryweapon _x} foreach((allunits+alldeadmen) select{_x call bis_fnc_objectside==east});

The same example is far more readable with proper spacing, good variable names and intermediate results:

_weaponNames = [];
_allUnitsAliveAndDead = allUnits + allDeadMen;
_allEastAliveAndDead = _allUnitsAliveAndDead select { _x call BIS_fnc_objectSide == east };
{ _weaponNames pushBackUnique primaryWeapon _x } forEach _allEastAliveAndDead;

Constants

Using a hard coded constant more than once? Use preprocessor directives rather than storing it in memory or cluttering your code with numbers. Such as:

a = _x + 1.053;
b = _y + 1.053;

And

_buffer = 1.053;
a = _x + _buffer;
b = _y + _buffer;

Becomes

#define BUFFER 1.053 // note: no semicolon
_a = _x + BUFFER;
_b = _y + BUFFER;

This also allows quick modifying of code; with the obvious loss of dynamics, but in that case it isn't a constant anymore.

Optimise then

Once you know what is what, you can understand your code better.

Use private variables instead of global variables (preceded with an underscore) as much as possible
You were iterating multiple times on the same array?
- You should be able to spot your issue now.
Are you using execVM on the same file, many times?
- Store your function in memory to avoid file reading every call with _myFunction = compile preprocessFileLineNumbers "myFile.sqf";
Is your variable name far too long?
- Find a smaller name, according to the variable scope:

e.g

{ _opforUnitUniform = uniform _x; systemChat _opforUnitUniform; } forEach _allOpforUnits;

becomes

{ _uniform = uniform _x; systemChat _uniform; } forEach _allopforUnits;