Is spawning script as function performance friendly?

[kibaBG 53]

Hi, I am spawning some motorized reinforcements as functions. They work fine but I have the feeling that performance gets worse then if I just execVM them ...

//initServer.sqf
_handle = 0 spawn { sleep 3600; call KIB_fnc_mehSqus; sleep 1800; call KIB_fnc_mehSqru; sleep 1800; call KIB_fnc_mehSqus;};

// fn_mehSqus.sqf
// troops are doing exactly what I want - they use the BTR to hunt down players 
// then get out from the vehicle shoot and if no player is alive they get it and continue to hunt down other players

reinfGRP = createGroup [independent,true];
_reinfGRP allowFleeing 0;
private _spos = [battle_flg, 0, 500, 5, 0, 0.25] call BIS_fnc_findSafePos;
private _reinfVeh = [_spos, 0, "rhsgref_cdf_btr80", _reinfGRP] call BIS_fnc_spawnVehicle;
private _u1 = _reinfGRP createUnit ["rhsgref_cdf_para_squadleader", _reinfGRP, [], 0, "CARGO"];
private _u2 = _reinfGRP createUnit ["rhsgref_cdf_para_machinegunner", _reinfGRP, [], 0, "CARGO"];
private _u3 = _reinfGRP createUnit ["rhsgref_cdf_para_grenadier_rpg", _reinfGRP, [], 0, "CARGO"];
private _u4 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u5 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u6 = _reinfGRP createUnit ["rhsgref_cdf_para_machinegunner", _reinfGRP, [], 0, "CARGO"];
private _u7 = _reinfGRP createUnit ["rhsgref_cdf_para_grenadier_rpg", _reinfGRP, [], 0, "CARGO"];
private _u8 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u9 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u10 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u11 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u12 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u13 = _reinfGRP createUnit ["rhsgref_cdf_para_rifleman", _reinfGRP, [], 0, "CARGO"];
private _u14 = _reinfGRP createUnit ["rhsgref_cdf_para_medic", _reinfGRP, [], 0, "CARGO"];
_reinfGRP addEventHandler ["EnemyDetected", {
	commandGetOut _u1;
	commandGetOut _u2;
	commandGetOut _u3;
	commandGetOut _u4;
	commandGetOut _u5;
	commandGetOut _u6;
	commandGetOut _u7;
	commandGetOut _u8;
	commandGetOut _u9;
	commandGetOut _u10;
	commandGetOut _u11;
	commandGetOut _u12;
	commandGetOut _u13;
	commandGetOut _u14;
}];
private _stalking = [_reinfGRP, alpha, 10, 20] spawn BIS_fnc_stalk;

Or maybe the cause is the event handler?

[Nemanjic 71]

As far as I know, exec is happening only at the moment it is called while handlers are tracking the game waiting for conditions to be fulfilled and that time interval is under the survivance of handlers which is the reason for more performance usage. I am not sure about this someone will know for sure. 

[mrcurry 496]

14 hours ago, kibaBG said:

They work fine but I have the feeling that performance gets worse then if I just execVM them ...

Never "feel" performance, if you think you have a performance-issue check the numbers.

When you measure the impact of your suspected thief you must do so in a controlled environment where the only difference is your suspect. Is the difference noticeable? 

If the answer is No then don't fix that which ain't broke 😉

If Yes, what does those numbers tell you? Is it worth the change?

 

As for your code it does have a few issues which likely are causing you syntax errors or messages being logged in the .rpt-files (which btw can degrade performance if it happens a lot in a short timespan)

1. reinfGRP and _reinfGRP are not the same variable. If you need them to point to the same group then you need to execute: private _reinfGRP = reinfGRP after creating the group.

2. Event handler code is not executed in the same scope as where the event handler is added. This means the _u1-14 variables are undefined inside the event handler, this is likely printing some errors in your logs as well. 
   This also means your "commandGetOut" calls will never do anything. If you are already getting the correct behavior you can just remove the event handler all together.

 

15 hours ago, Nemanjic said:

As far as I know, exec is happening only at the moment it is called while handlers are tracking the game waiting for conditions to be fulfilled and that time interval is under the survivance of handlers which is the reason for more performance usage.

Generally Events/Event handlers are considered more performant than script and for 2 main reasons:

1. The engine handles the triggering of the Event when it happens in the simulation, no need to check the conditions continuously.
2. Handler-code only runs once a particular Event happens (e.g. "Object #1234 was killed"), in the meantime they are just stored in memory ready to be accessed.

In essence Event handlers are just "listeners" for events, they do not check the conditions for those events themselves.

Since the engine is already spending a lot (in CPU terms) of time handling things like "people dying from bullets" and all the other stuff, it doesn't take a lot of extra work for it to also shout "Hey this guy is dead". At that point the "listeners" wake up and do their thing (bury the body, boobytrap the body or do unspeakable things to the body).

 

In actuality an event handler doesn't "listen" but rather it gets registered to a list (usually). When the Event happens in the simulation the game gets the list of all registered Handlers and calls them one by one (in a predetermined order).

If you want to know more (though not directly related to the game) you can check out the Observer-pattern wikipedia page.

 

Be aware though that Event handlers aren't a magical "fix-performance"-button. You need to understand what they do so you can use them in situations where they excel.

[kibaBG 53]

@mrcurry Sorry, I made a mistake, its "_reinfGRP" in my script, somehow the underscore got deleted. I tested the script without the event handler and you are right, it does nothing, the group behaves as they should without it.
I measure performance by looking the Steam fps indicator in-game when I run the script, I don't know any other way to measure it ... My main issue was if using "spawn" will be more expensive than "execVM" but I tested in dedicated server and there I don't see any difference in fps counter.  


 

[mrcurry 496]

1 hour ago, kibaBG said:

measure performance by looking the Steam fps indicator

Perfectly valid for testing for release since its also the metric most players are likely to use.

 

For small snippets of code you can use the performance test button in the debug console.

 

For larger, more complex code you can also take the diag_tickTime before and after the relevant code to get total time spent. Just keep in mind pauses (e.g. sleep, waitUntil) or "call and continue" commands (e.g. spawn, exec, execVM) when you make your measurements.

[Larrow 2821]

6 hours ago, kibaBG said:

My main issue was if using "spawn" will be more expensive than "execVM"

ExecVM will be more expensive than spawn, as execVM always compiles the script every time the command is used( best for one-off, rarely used code ), whereas spawn-ing a function which is registered in CfgFunctions( or globally defined in some init script ) the function is compiled once at mission load.

[thy_ 157]

Quote

Is spawning script as function performance friendly?

 

YES!

 

You can spawn whatever you want through CSWR (performance friendly because it doesn't change any original AI behavior, and its persistent loops are super limited to provide a balanced performance with a lot of AI living to the mission)