Eventhandlers are compiled before every execution
Reviewed, NormalPublic
Actions

Description

Not a bug but rather an enhancement.
Arma eventhandlers (ctrlAddEventhandler,addMissionEventHandler,onEachFrame,onMapSingleClick,...) Are stored as Strings in the engine and are compiled before every execution.
This causes

addMissionEventHandler ["EachFrame", addon_fnc_onEachFrame];

To recompile the whole addon_fnc_onEachFrame each frame. Which may be a potentially big function which takes long to compile.
If you instead do this:

addMissionEventHandler ["EachFrame", {call addon_fnc_onEachFrame}];

It looks like it would be slower because you have an additional call. But actually this is about 16x or more faster because it only has to compile that small code segment instead of a big file.

Details

Severity: Tweak
Resolution: Open
Reproducibility: Always
Operating System: Windows 7
Category: Scripting

Steps To Reproduce

Function designed to stress compiler

TestingFunction = {
    if (true) exitWith {};
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
    {call { call {call{}}}} forEach variableStuff;
    missionNamespace getVariable ["",{call{call { call {call{}}}} forEach variableStuff;}];
};

execute

removeAllMissionEventHandlers "EachFrame";
for [{_i=0}, {_i<1000}, {_i=_i+1}] do {addMissionEventHandler ["EachFrame", {call TestingFunction}];};

check Framerate. It's not good ofcause because you have 1k EachFrame Eventhandlers.
Now try this

removeAllMissionEventHandlers "EachFrame";
for [{_i=0}, {_i<1000}, {_i=_i+1}] do {addMissionEventHandler ["EachFrame", TestingFunction];};

You still have the same amount of EachFrame Eventhandlers. But check your FPS now.

using diag_captureFrame i got these results

for [{_i=0}, {_i<1000}, {_i=_i+1}] do {addMissionEventHandler ["EachFrame", TestingFunction];}; //~760ms per frame
for [{_i=0}, {_i<1000}, {_i=_i+1}] do {addMissionEventHandler ["EachFrame", {call TestingFunction}];}; // ~47ms per frame

Event Timeline

dedmen created this task.Feb 14 2017, 5:51 AM

dedmen edited Steps To Reproduce. (Show Details)Feb 14 2017, 6:00 AM

Torndeco added a subscriber: Torndeco.Feb 14 2017, 6:22 AM

Lex added a subscriber: Lex.Feb 14 2017, 2:17 PM

Alwin changed the task status from New to Reviewed.Feb 14 2017, 3:25 PM

bux578 added a subscriber: bux578.Feb 14 2017, 4:43 PM

Dwarden added a subscriber: Dwarden.Feb 14 2017, 6:05 PM

thanks, we will take look into this

Gnashes added a subscriber: Gnashes.Feb 14 2017, 6:46 PM

Dscha also checked if the BIS functions were influenced by that and he only found

if (isNil "bis_revive_iconEH") then {bis_revive_iconEH = addMissionEventHandler ["Draw3D",bis_revive_draw];};

Meaning there is atleast this one BIS function that gets a performance penalty because of this.

SuicideKing added a subscriber: SuicideKing.Feb 14 2017, 8:02 PM

GBee added a subscriber: GBee.Feb 15 2017, 12:01 PM

NetFusion added a subscriber: NetFusion.Feb 15 2017, 12:56 PM

jokoho482 added a subscriber: jokoho482.Feb 16 2017, 4:21 AM

Is this for all events (object,display,control) or just stackable mission events?

@MDCCLXXVI

https://forums.bistudio.com/topic/151099-scripting-discussion-dev-branch/?page=48#comment-3152906

kju-PvPscene added a subscriber: kju-PvPscene.Feb 16 2017, 8:30 PM

GunnyTomHighway added a subscriber: GunnyTomHighway.Feb 17 2017, 12:42 PM

Please could you precise how do you pass arguments in such EH as handleDamage, hit or teamSwitch?
for example, I had workable :
player addEventHandler ["HandleDamage",{

_unit = _this select 0;
if (vehicle _unit isKindOf "plane") then {_dam = 0} else {_dam = _this select 2};
_dam

}];
so, i can't find a solution like:
fn_plane = {

_unit = _this select 0;
if (vehicle _unit isKindOf "plane") then {_dam = 0} else {_dam = _this select 2};
_dam

};
player addEventHandler ["HandleDamage", _this call fn_plane];
or
player addEventHandler ["HandleDamage", {_this call fn_plane}];
or anything else.
I miss something but what?
Thanks

@PiepMGI Your code is too small to be noticably affected by this issue.

What you want is this

fn_plane = {
params ["_unit","_dam"];
if (vehicle _unit isKindOf "plane") then {_dam = 0};
_dam
};

player addEventHandler ["HandleDamage", {call fn_plane}];

But as I said your code is too small to matter.

Thank you. This topic is very interesting. I have some heavier codes than this one. It was just to understand how are working parameters code inside the EH.

Lex removed a subscriber: Lex.Mar 17 2017, 12:26 PM

ViperMaul added a subscriber: ViperMaul.Apr 5 2017, 3:25 PM

SilentSpike added a subscriber: SilentSpike.May 10 2017, 4:34 PM

Update due to latest changes BIS_fnc_addStackedEventHandler is now also suffering from this on dev-branch. That change looks to be intended like that.
Besides that change also breaks any non-string and non-number argument passed to the StackedEH because someone apparently doesn't understand how format works.
But that's just KK being KK again.

Maybe that get's fixed again before that change is pushed. Probably not though.

Make BIS_fnc_addStackedEventHandler great again!

But that's just KK being KK again

Not my fault it is broken ;)

@BIS_fnc_KK Who wrote this then compile format ["%1 call %2", _arguments, _code] ?
You already broke a bit of stuff lately so sorry for defaulting to blame you. I don't see anybody else doing bigger reworks on SQF stuff.

Can confirm that this is broken. This is not the proper way to pass arguments to a function!

ConnorCableTV added a subscriber: ConnorCableTV.Aug 28 2017, 9:33 AM

ConnorCableTV removed a subscriber: ConnorCableTV.

PhILoX added a subscriber: PhILoX.Nov 24 2017, 2:15 PM

nomisum added a subscriber: nomisum.Nov 24 2017, 5:17 PM

No updates on this?

GunnyTomHighway removed a subscriber: GunnyTomHighway.Dec 25 2018, 3:02 PM

shukari added a subscriber: shukari.Dec 29 2018, 4:38 AM

PR9INICHEK added a subscriber: PR9INICHEK.Jan 10 2019, 8:42 AM

oukej added a subscriber: oukej.Jan 29 2019, 4:16 PM

Digitals added a subscriber: Digitals.Apr 1 2019, 11:22 PM

Real needs to be done as suggested, I think.