ExecVM // Compile // Functions.hpp

[JeyR 2]

Hello. I am pretty sure this is a question that has been answered many many times but I really can't make differences between each of the forums topics that I have found so far. Everyone tells the same, yet for a totally different question. So I thought I might as well just create a topic and ask my questions here. Pretty sure someone will answer it sooner or later.

1. When I have multiple functions, in multiple SQFs, is it better to call them 1 by 1 with ExecVM or call them with compile or should I create functions.hpp ?
-I want to use all of the scripts, and most of them are going to be used later in the mission.
-Most of the scripts have a return value
-Is there going to be any performance difference?

2. If I have a really huge script, (literally a random mission spawner with multiple arrays and public variables) is it better to compile it or execVM it?
-The script is called each time a mission is finished.
-It contains loops and many scopes
-It doesn't return anything

3. If I have scripts that I want to run only on the client side, and not on the server side, do I still need to execVM it on the server?
-Respawn scripts / spawn protection / addactions
-Contains loops

Furthermore, I want to know what is the time difference between execVM and Call?
If I run bug functions multiple times, do they have a performance impact on the server? For example in the case of creating private arrays again, etc.
 

[Grumpy Old Man 3540]

From a general consensus I guess it sums up to this:

 

If a function has to run only once and on mission start only it's fine to use execVM.

When having to run a function multiple times execVM slows down the execution since it has to compile the script every time, this also depends on the size of the file.

 

Best practice is to simply put every function and file into your own functions library, so stuff can be compiled upon mission start and stays in memory increasing access speed.

Bullet list from the linked page:

Quote

Main benefits:

1. Automatic compilation upon mission start into a global variable - no need to remember direct paths to files.
2. Anti-hack protection using compileFinal (see Recompiling for more info)
3. Listing in the Functions Viewer
4. Advanced debugging options
5. Optional immediate execution upon mission start, without need for manual call
6. Potential performance improvements

 

 

You can also define if a function has to be run during preInit or postInit, opening up possibilities that can not be done with execVM.

Functions in preInit can be used to do CPU intense stuff, since simulation doesn't run at this point.

 

There's probably some stuff I forgot but I think that's pretty much it.

 

Cheers

 

[Muzzleflash 111]

To be honest I don't bother with the functions module. I find that it is cumbersome to make the definitions, and I make modules, not functions (that is several functions in one file), and it doesn't support that. For the benefits, benefits compared to what?

#1 and #5 was long solved before there was anything called functions module.

#2 Anti-hack protection. I suppose some people got something out of this. But for "closed" clans I refer to it as anti-hotfix protection - preventing us from fixing bugs, that the authors (including BIS) either can't, doesn't want to bother to, fix (at least in reasonable time). So for some it may have been a benefit; personally I have gotten zero benefits, only trouble. Also you can use compileFinal without making a functions library.

#3 Agree this is a benefit. Particularly if you are making a library. But for private consumption it is way overkill since you already have your source, and know/can easily look up the parameters.

#4 Can someone tell me what this actually includes? From the BIKI page the only related is logging and error functions which you can call anyway.

#6 Potential? In what sense, and is it still only "potential".

 

1. But let me end the rant and answer your question. If you are going for performance. Any script/function/name-whatever you are going to run more than once, should be compiled into a variable. The performance benefit is dependent on how often you run the functions/scripts.

2. It really doesn't matter (like at all) since you call it so rarely, but I would still compile it into a variable.

3. No, you don't have to.

 

Your final comment. First of all compile and execVM are not comparable at all. Basically

 

X execVM "myfile.sqf" is equivalent to this:  X spawn (compile preProcessFile "myfile.sqf");

[JeyR 2]

Wow guys that was really helpful. Thanks a lot. Now there is only1 thing I might not understand so let me ask it. Basically if I do this= call compile preprocessfilelinenumbers myscript.sqf . It's equal to creating a functions library right? Because then I can call my functions that are inside the sqf.

[das attorney 857]

It's not quite the same.  To make it the same as CfgFunctions you would need to do:

 

this= call compileFinal preprocessfilelinenumbers myscript.sqf

 

But then, you should do:

 

fnc_blabla = compileFInal preprocessfilelinenumbers myscript.sqf

 

call fnc_blabla

call fnc_blabla

 

Only compile (or compileFinal) it once.