Lou Montana/Sandbox – User
Lou Montana (talk | contribs) (First Code Optimisation sharing) |
Lou Montana (talk | contribs) m (WIP) |
||
Line 1: | Line 1: | ||
{{ | {{Informative|This page is an intended replacement for '''[[Code Optimisation]]'''. It is obviously '''a WORK-IN-PROGRESS'''.}} | ||
[[Category:Sandbox]] | [[Category:Sandbox]] | ||
<!-- | <!-- | ||
TODO: color code about importance of performance saving? (green / yellow / red) | TODO: color code about importance of performance saving? (green / yellow / red) | ||
--> | --> | ||
---- | |||
__NOEDITSECTION__ | |||
<div style="float: right; margin-left: 1.5em; margin-bottom: 1em; max-width: 25%;">__TOC__</div> | |||
= Code Optimisation = | = Code Optimisation = | ||
Line 24: | Line 26: | ||
=== Make it readable === | === Make it readable === | ||
Whether you are cleaning your code or a different person's, you must understand the code | Whether you are cleaning your code or a different person's, you must understand the code without twisting your brain: | ||
* While [[SQF syntax|SQF]] ''is'' impacted by variable name length, this should not take precedence on the fact that code must be readable by a human being. | * While [[SQF syntax|SQF]] ''is'' 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 not worth the headache it gives when trying to read it. Don't overuse it. | * ''One-lining'' (putting everything in one statement) memory improvement is 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. | * Indentation is important for the human mind, and space is too. Space is free, use it. | ||
* Finally, camel-casing (namingLikeThis) your variables and commands will naturally make the code more readable, especially for long names. | * Finally, camel-casing (namingLikeThis) your variables and commands will naturally make the code more readable, especially for long names. | ||
{{Informative| '''_i''' is an accepted variable standard for a [[for]]..[[do]] iteration}} | |||
See the following code: | See the following code: | ||
<code>_w=[];{_w pushbackunique primaryweapon _x}foreach((allunits+alldeadmen)select{_x call bis_fnc_objectside==east});</code> | <code style="clear: right;">_w=[];{_w pushbackunique primaryweapon _x}foreach((allunits+alldeadmen)select{_x call bis_fnc_objectside==east});</code> | ||
The same example is far more readable with proper spacing, good variable names and intermediate results: | The same example is far more readable with proper spacing, good variable names and intermediate results: | ||
Line 52: | Line 56: | ||
* Is your function code far too long? | * Is your function code far too long? | ||
** Split it in understandable-sized bites, for your own sanity. | ** Split it in understandable-sized bites, for your own sanity. | ||
* 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 | |||
Line 58: | Line 68: | ||
=== Successive condition check === | === Successive condition check === | ||
In [[SQF syntax|SQF]] the following code will check '''all and every''' condition, even if one fail: | In [[SQF syntax|SQF]] the following code will check '''all and every''' condition, even if one fail: | ||
[[if]] (condition1 && condition2 && condition3) [[then]] { /* thenCode */ }; | [[if]] (condition1 && condition2 && condition3) [[then]] { {{codecomment|/* thenCode */}} }; | ||
e.g: | e.g: | ||
[[if]] ([[alive]] unit1 && [[not]] [[alive]] aPvehicle && [[daytime]] > 5) [[then]] { /* thenCode */ }; | [[if]] ([[alive]] unit1 && [[not]] [[alive]] aPvehicle && [[daytime]] > 5) [[then]] { {{codecomment|/* thenCode */}} }; | ||
This code will check if {{Inline code|unit1}} is alive, and if it is not {{Inline code|[[not]] [[alive]] aPvehicle && [[daytime]] > 5}} will execute anyway. | This code will check if {{Inline code|unit1}} is alive, and if it is not {{Inline code|[[not]] [[alive]] aPvehicle && [[daytime]] > 5}} will execute anyway. | ||
To avoid this behaviour, you can either imbricate [[if|ifs]] or use '''lazy evaluation''' such as the following: | To avoid this behaviour, you can either imbricate [[if|ifs]] or use '''lazy evaluation''' such as the following: | ||
[[if]] ([[alive]] unit1 && { [[not]] [[alive]] aPvehicle } && {{ [[daytime]] > 5}}) [[then]] { /* thenCode */ }; | [[if]] ([[alive]] unit1 && { [[not]] [[alive]] aPvehicle } && {{ [[daytime]] > 5}}) [[then]] { {{codecomment|/* thenCode */}} }; | ||
This lazy evaluation will stop code execution on the first [[false]] statement. | This lazy evaluation will stop code execution on the first [[false]] statement. | ||
Line 70: | Line 80: | ||
[true || {false} || {false}] call BIS_fnc_codePerformance; {{codecomment|// fastest}} | [true || {false} || {false}] call BIS_fnc_codePerformance; {{codecomment|// fastest}} | ||
[true || false || false ] call BIS_fnc_codePerformance; {{codecomment|// normal}} | [true || false || false ] call BIS_fnc_codePerformance; {{codecomment|// normal}} | ||
[false || false || false ] call BIS_fnc_codePerformance; {{codecomment|// | [false || false || false ] call BIS_fnc_codePerformance; {{codecomment|// normal}} | ||
[false || {false} || {false}] call BIS_fnc_codePerformance; {{codecomment|// slowest}} | [false || {false} || {false}] call BIS_fnc_codePerformance; {{codecomment|// slowest}} | ||
==== Adding large strings together ==== | ==== Adding large strings together ==== | ||
{{Inline code|a = a + b}} works fine for small strings, however the bigger the string gets the slower this becomes: | |||
s = ""; [[for]] "_i" [[from]] 1 [[to]] 10000 [[do]] {s = s + "123"}; {{codecomment|// 30000 chars @ 290ms}} | s = ""; [[for]] "_i" [[from]] 1 [[to]] 10000 [[do]] {s = s + "123"}; {{codecomment|// 30000 chars @ 290ms}} | ||
The solution is to use a string array that you will concatenate later: | The solution is to use a string array that you will concatenate later: | ||
strings = []; [[for]] "_i" [[from]] 1 [[to]] 10000 [[do]] {strings [[pushBack]] "123"}; strings = strings [[joinString]] ""; {{codecomment|// 30000 chars @ 30ms}} | strings = []; [[for]] "_i" [[from]] 1 [[to]] 10000 [[do]] {strings [[pushBack]] "123"}; strings = strings [[joinString]] ""; {{codecomment|// 30000 chars @ 30ms}} | ||
Line 91: | Line 102: | ||
== Equivalent commands performance == | == Equivalent commands performance == | ||
=== if === | === if === | ||
Use: | Use: | ||
[[if]] (condition1) then {/* thenCode */} else {/* elseCode */}; {{codecomment|// faster}} | [[if]] (condition1) [[then]] { {{codecomment|/* thenCode */}} } else { {{codecomment|/* elseCode */}} }; {{codecomment|// faster}} | ||
Instead of: | Instead of: | ||
[[if]] (condition1) then [{/* thenCode */}, {/* elseCode */}]; {{codecomment|// slower}} | [[if]] (condition1) [[then]] [{ {{codecomment|/* thenCode */}} }, { {{codecomment|/* elseCode */}} }]; {{codecomment|// slower}} | ||
=== for === | === for === | ||
Use: | Use: | ||
[[for]] " | [[for]] "_i" [[from]] 0 [[to]] 100 [[do]] { {{codecomment|/* forCode */}} }; {{codecomment|// faster}} | ||
Instead of: | Instead of: | ||
[[for]] [{_i = 0}, {_i < 100}, {_i = _i + 1}] [[do]] { /* forCode */ }; {{codecomment|// slower}} | [[for]] [{_i = 0}, {_i < 100}, {_i = _i + 1}] [[do]] { {{codecomment|/* forCode */}} }; {{codecomment|// slower}} | ||
=== forEach vs count === | === forEach vs count === | ||
Line 183: | Line 193: | ||
=== Config path delimiter === | === Config path delimiter === | ||
{{Inline code|>>}} is slightly faster than {{Inline code|/}} when used in config path with [[configFile]] or [[missionConfigFile]]: | |||
[[configFile]] >> "CfgVehicles" {{codecomment|// 0.0019 ms}} | [[configFile]] >> "CfgVehicles" {{codecomment|// 0.0019 ms}} | ||
is (very slighlty) faster than | is (very slighlty) faster than | ||
Line 189: | Line 199: | ||
=== getPos* and setPos* === | === getPos* and setPos* === | ||
[[getPosWorld]] {{codecomment|// 0.0015 ms}} | |||
//0. | [[getPosASL]] {{codecomment|// 0.0016 ms}} | ||
[[getPosATL]] {{codecomment|// 0.0016 ms}} | |||
[[getPos]] {{codecomment|// 0.0020 ms}} | |||
[[position]] {{codecomment|// 0.0020 ms}} | |||
[[getPosVisual]] {{codecomment|// 0.0021 ms}} | |||
[[visiblePosition]] {{codecomment|// 0.0021 ms}} | |||
[[getPosASLW]] {{codecomment|// 0.0023 ms}} | |||
[[setPosWorld]] {{codecomment|// 0.0060 ms}} | |||
// | [[setPosASL]] {{codecomment|// 0.0060 ms}} | ||
[[ | [[setPosATL]] {{codecomment|// 0.0060 ms}} | ||
//0. | [[setPos]] {{codecomment|// 0.0063 ms}} | ||
[[setPosASLW]] {{codecomment|// 0.0068 ms}} | |||
[[setVehiclePosition]] {{codecomment|// 0.0077 ms "CAN_COLLIDE"}} | |||
{{codecomment|// 0.0390 ms "NONE"}} | |||
Line 230: | Line 236: | ||
* '''Concatenating:''' {{Inline code|myArray {{=}} myArray [[valuea_plus_valueb|+]] [element]}} has been ''reinforced'' by [[append]]: if you don't need the original array to be modified, use + | * '''Concatenating:''' {{Inline code|myArray {{=}} myArray [[valuea_plus_valueb|+]] [element]}} has been ''reinforced'' by [[append]]: if you don't need the original array to be modified, use + | ||
* '''Comparing:''' use [[isEqualTo]] instead of [[BIS_fnc_areEqual]] or a custom comparison function | * '''Comparing:''' use [[isEqualTo]] instead of [[BIS_fnc_areEqual]] or a custom comparison function | ||
** {{Inline code|[[count]] myArray == 0}} is pretty fast, but direct comparison with [[isEqualTo]] is | ** {{Inline code|[[count]] myArray {{=}}{{=}} 0}} is pretty fast, but direct comparison with [[isEqualTo]] is still a little faster: {{Inline code|myArray [[isEqualTo]] []}} | ||
* '''Finding common items:''' [[in]] [[forEach]] loop has been replaced by [[arrayIntersect]] | * '''Finding common items:''' [[in]] [[forEach]] loop has been replaced by [[arrayIntersect]] | ||
* '''Condition filtering:''' [[forEach]] can be replaced by [[select]] (alternative syntax) | * '''Condition filtering:''' [[forEach]] can be replaced by [[select]] (alternative syntax) |
Revision as of 13:19, 9 May 2018
Code Optimisation
Introduction
This article will try to be a general guide about improving your code and its performance.
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
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 damage.
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 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 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.
- Finally, camel-casing (namingLikeThis) your variables and commands will naturally make the code more readable, especially for long names.
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;
- 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.
Optimise then
Once you know what is what, you can understand your code better.
- You were iterating multiple times on the same array?
- You should be able to spot your issue now.
- Do you see the same code, but with different parameters?
- Time to write a function.
- 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";
- Store your function in memory to avoid file reading every call with
- Is your function code far too long?
- Split it in understandable-sized bites, for your own sanity.
- 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
Code optimisation
Successive condition check
In SQF the following code will check all and every condition, even if one fail:
if (condition1 && condition2 && condition3) then { /* thenCode */ };
e.g:
if (alive unit1 && not alive aPvehicle && daytime > 5) then { /* thenCode */ };
This code will check if unit1
is alive, and if it is not not alive aPvehicle && daytime > 5
will execute anyway.
To avoid this behaviour, you can either imbricate ifs or use lazy evaluation such as the following:
if (alive unit1 && { not alive aPvehicle } && {{ daytime > 5}}) then { /* thenCode */ };
This lazy evaluation will stop code execution on the first false statement.
Using lazy evaluation is not always the best way as it could speed up the code as well as slow it down, depending on the current condition being evaluated:
[true || {false} || {false}] call BIS_fnc_codePerformance; // fastest [true || false || false ] call BIS_fnc_codePerformance; // normal [false || false || false ] call BIS_fnc_codePerformance; // normal [false || {false} || {false}] call BIS_fnc_codePerformance; // slowest
Adding large strings together
-No code provided-
works fine for small strings, however the bigger the string gets the slower this becomes:
s = ""; for "_i" from 1 to 10000 do {s = s + "123"}; // 30000 chars @ 290ms
The solution is to use a string array that you will concatenate later:
strings = []; for "_i" from 1 to 10000 do {strings pushBack "123"}; strings = strings joinString ""; // 30000 chars @ 30ms
Multiplayer recommendations
TODO
- no publicVariable or public setVariable at high frequency
- the server is supposed to have a lot of memory, use it
createSimpleObject vs createVehicle
TODO create at [0,0,0]
Equivalent commands performance
if
Use:
if (condition1) then { /* thenCode */ } else { /* elseCode */ }; // faster
Instead of:
if (condition1) then [{ /* thenCode */ }, { /* elseCode */ }]; // slower
for
Use:
for "_i" from 0 to 100 do { /* forCode */ }; // faster
Instead of:
for [{_i = 0}, {_i < 100}, {_i = _i + 1}] do { /* forCode */ }; // slower
forEach vs count
Both commands will step through supplied array of elements one by one and both commands will contain reference to current element in the _x variable.
However, count loop is a little faster than forEach loop, but it does not have _forEachIndex variable.
Also, there is a limitation as the code inside count expects Boolean or Nothing while itself returns Number.
{diag_log _x} count [1,2,3,4,5,6,7,8,9]; // faster
{diag_log _x} forEach [1,2,3,4,5,6,7,8,9]; // slower
Usage:
_someoneIsNear = {_x distance [0,0,0] < 1000} count allUnits > 0;
_someoneIsNear = { if (_x distance [0,0,0] < 1000) exitWith { true }; false } forEach allUnits;
TODO: findIf?
+ and format
When concatenating more than two strings, format is faster than +. Use:
format ["%1%2%3%4%5", "string1", "string2", "string3", "string4", "string5"]; // faster
Instead of:
"string1" + "string2" + "string3" + "string4" + "string5"; // slower
select and if
Use:
result = ["false result", "true result"] select _condition; // faster
Instead of the lazy-evaluated if:
result = if (_condition) then { "true result"; } else { "false result"; }; // slower
private
Use:
private _a = 1;
private _b = 2;
private _c = 3;
private _d = 4;
// 0.0023 ms
Instead of:
private ["_a", "_b", "_c", "_d"];
_a = 1;
_b = 2;
_c = 3;
_d = 4;
// 0.0040 ms
However:
for "_i" from 1 to 100 do { private _a = 1; private _b = 2; private _c = 3; private _d = 4; }; // 0.186776 ms
is slower than:
private ["_a", "_b", "_c", "_d"];
for "_i" from 1 to 100 do
{
_a = 1;
_b = 2;
_c = 3;
_d = 4;
};
// 0.146327 ms
The reason behind this is that in the first example variables are created, assigned and deleted in each loop.
In the second example the variables are only created/deleted once and changed often.
objectParent and vehicle
isNull objectParent player // 0.0013 ms, slightly faster
vehicle player == player // 0.0022 ms
nearEntities and nearestObjects
- nearEntities is much faster than nearestObjects given on range and amount of object(s) which are within the given range.
If a range was set to more thean 100 meters it is highly recommend to use nearEntities instead of nearestObjects.
Note: nearEntities only searches for objects which are alive. Killed units, destroyed vehicles, static objects and buildings will be ignored by the nearEntities command.
Config path delimiter
>>
is slightly faster than /
when used in config path with configFile or missionConfigFile:
configFile >> "CfgVehicles" // 0.0019 ms
is (very slighlty) faster than
configFile / "CfgVehicles" // 0.0023 ms
getPos* and setPos*
getPosWorld // 0.0015 ms getPosASL // 0.0016 ms getPosATL // 0.0016 ms getPos // 0.0020 ms position // 0.0020 ms getPosVisual // 0.0021 ms visiblePosition // 0.0021 ms getPosASLW // 0.0023 ms
setPosWorld // 0.0060 ms setPosASL // 0.0060 ms setPosATL // 0.0060 ms setPos // 0.0063 ms setPosASLW // 0.0068 ms setVehiclePosition // 0.0077 ms "CAN_COLLIDE" // 0.0390 ms "NONE"
Conversion from earlier versions
Each iteration of Bohemia games (Operation Flashpoint, Arma, Arma 2, Take On Helicopters, Arma 3) brought their own new commands, especially Arma 2 and Arma 3.
For that, if you are converting scripts from older versions of the engine, some aspects should be reviewed:
Loops
Array operations
- Adding an item:
myArray + [element]
andmyArray set [count myArray, element]
have been replaced by pushBack - Selecting a random item: BIS_fnc_selectRandom has been replaced by selectRandom
- Removing items:
myArray set [1, objNull]; myArray - [objNull]
has been replaced by deleteAt and deleteRange - Concatenating:
myArray = myArray + [element]
has been reinforced by append: if you don't need the original array to be modified, use + - Comparing: use isEqualTo instead of BIS_fnc_areEqual or a custom comparison function
- Finding common items: in forEach loop has been replaced by arrayIntersect
- Condition filtering: forEach can be replaced by select (alternative syntax)
result = [];
{
if (_x % 2 == 0) then
{
result pushBack _x;
};
} forEach arrayOfNumbers; // 2.57 ms
result = (arrayOfNumbers select { _x % 2 == 0 }); // 1.55 ms
String operations
String manipulation has been simplified with the following commands:
- string select index
- toArray and toString have been reinforced with splitString and joinString
Multiplayer
- BIS_fnc_MP has been replaced by remoteExec and remoteExecCall