Script efficiency

[zapat 56]

Thanks, I've found some new info here.

One thing I don't understand:

for "_y" from # to # step # do { ... }

is faster than

for [{ ... },{ ... },{ ... }] do { ... }

?

What does it mean? How can it be faster? Should I rewrite all my code to the second option?

[Muzzleflash 111]

I'm guessing you refer to the actual loop construct since it would be weird if the block inside executed faster. It can be faster because the engine have implemented the first loop type better than the second?

Whether you should rewrite: Well clearly your code functions fine as it is now. I would presume the actual performance gain would be proportional to the number of cycles your loops perform. So unless you want to rewrite everything just do it on the loops with many iterations.

I have rarely seen anyone actually use the second form so my guess is that most people use the first form. I use the first form since it easier to type on non-us keyboards. Also you don't need to specify the step if it is 1:

for "_i" from 0 to 9 do {...};

[gammadust 12]

@Zonekiller

Well that was a bit uncalled for, I don't think anyone was exacly picking on your coding/scripting habits, maybe just expecting you to obviate the reasons one should prioritise one way or another.

In regards to braces, I always use them whenever in doubt about priority of operators, but soon enough they get redundant and clutter legibility, and drop them when doubts are clear. If one was to follow the rule stricly I suspect your own code would be much more cluttered, somehow the amount of braces you feel confortable with are those and not less.

...
waituntil {([color="Red"]([/color]_veh distance _delivery_spot[color="Red"])[/color] < 20)}; // making the [i]distance[/i] (as operator) more obvious
...

Let's say you mean "consistency" with your rule. Anyway I also find good practice to make explicit more stuff than the interpreter requires, specialy if you are sharing code. My shorcuts... are my shorcuts.

On code efficiency, I find your hint on chain of conditions still relevant even if it is basicaly the same for the engine performance, it implies having a clear mind about what one's trying to achieve and that can only be more efficient.

I was expecting more hints in the like of this:

Thanks, I've found some new info here.

One thing I don't understand:

for "_y" from # to # step # do { ... }

is faster than

for [{ ... },{ ... },{ ... }] do { ... }

?

What does it mean? How can it be faster? Should I rewrite all my code to the second option?

or looping through an array with a:

array = [(...),(...),(...)];
{
_x = somemanipulation
}foreach array;

benchmarking tools...

Well known good practices specific to arma scripting, etc..

@Zonekiller You will think I am picking again, but huge ammounts of text can be spoiled in order to keep the forum legible, as well as giving emphasis to relevant parts of the text.

[rübe 127]

Thanks, I've found some new info here.

One thing I don't understand:

for "_y" from # to # step # do { ... }

is faster than

for [{ ... },{ ... },{ ... }] do { ... }

?

What does it mean? How can it be faster?

Why do you even care? It's already way too late, if you really need to optimze stuff like this. And really; what could you gain by using the first variant over the second? Even with a high number of iterations, we're speaking about milliseconds here. And what matters is not the for-syntax you choose, but what you're actually doing each iteration.

As for why the second variant is a tiny wee bit slower; probably because it has to evaluate the condition and iterator each iteration, while the first variant doesn't have to do that many calculations to keep the loop going; the step is a fixed integer, while in the first variant the step can vary since the iterator is a function, not a fixed step... bla.

As you see, there's actually a reason for the second syntax. It's more powerfull.

Should I rewrite all my code to the second option?

Yeah, go ahead.. :p

[demonized 20]

Jumping in on this thread.

I have no coding experience whatsoever outside of armaverse, started fiddling with scripts in sqs when A1 was out, then with help and examples from Armaholic and BIS Forums i switched to sqf.

Arma scripting (sqs and sqf) is my only coding experience ever.

I consider myself a general user and scripter, most of us using all your scripts are.

My own habits is this, and its because it looks clean to me and it works for me, i can read it without to much effort:

single variables i leave alone:

if (_var) then {
// or
if (_var1 AND _var2 AND _var3 > 5) then {

dual variables compared to something i also leave alone:

if (group player == _grp) then {
// or
if (group _unit1 == group _unit2) then {

more than 2 variables i tend to encase:

if ( _unit in (units (group _unit2)) ) then {  // the in i see as a "divider" of the variable leaving left and right to single/dual/multiple habits.
// or
if ( (_unit1 distance _unit2) > 50 ) then {  // here the distance command is my "divider" and both left and right is single vars so i encase the whole variable as one.

some cases i use one extra just to make it clear to me that it stands out as 1 variable.

_random = _array select floor(random(count _array));
// this is more than good enough.

// but i use this below since ive experienced headaches in the past and it made me "see" the thing more clearly:

_random = _array select (floor(random(count _array)));
// here the select number stands out for me, oposed to above where i take longer to "see" it.

These are just my personal habits and i do them mainly because its easy for ME to read, second for ease of reading for others.

I try to not add in extra "stuff" when not needed, but sometimes its easier for me to add it, like in the "floor random count array" example.

[Double Doppler 10]

I do not advise setVehicleInit for MP scenarios. When I was testing my mission, the amount of data changed by using setVehicleInit and it's fact that this all gets processed on JIP meant that it was nearly impossible to join my test server during the middle of the game when I was constantly using it in a loop, resulting in the server closing the connection.

However, what is the performance as in public setVariable and getVariable? If the values are JIP, will that not make them taxing like setVehicleInit (sending the old variables right up to the latest ones each time a player joins the server)? I haven't used setVariable or getVariable before, nor do I full understand the concept of them yet, but are they performance taxing?

[shuko 59]

I think the difference is that setvehinit sends all the old variables while setvar only sends current/latest.

[Double Doppler 10]

One main concern is server FPS.

I have known missions with bad issues regarding this before, with FPS dropping down to 37 at only 2 players, and down to 15 with 6.

There were alot of user placed objects in the map, so does this take a toll on server FPS? IS there a way of measuring a full server's FPS without having 2+ players?

How much FPS would a script/function take on operation?

And how much would a single/few items placed in the editor tax performance? All these object-local variables such as position logging, damage logging and such forth...

Also, are there any efficient ways of broadcasting code without having to slow down connection? What is the bandwidth usage of a public Variable depending on size of code? What are the best practices of using this function?

Sending in large chunks of code through a single variable?

Or sending little commands with separate variables?

[twirly 11]

IS there a way of measuring a full server's FPS without having 2+ players?

I think you would need players to truly test the FPS.... a "suck it and see" deal.

How much FPS would a script/function take on operation?

Depends totally on what it does and how well it's written.

And how much would a single/few items placed in the editor tax performance?

Not much at all.

Also, are there any efficient ways of broadcasting code without having to slow down connection?

PVEH's are your best bet.... as only the variables are transferred. Bandwith usage should be negligible.... but again this would depend on what it does and how its written. Transmitting a variable a 100 times a second can't be good.

[galzohar 31]

As long as you don't broadcast a variable too often you should be good. Can't tell exactly how often, but I remember there used to be an old bug in ACE where something would get PVed 10 times a second and that would cause some serious network lag. PVing 1-2 vars every 30 seconds, on the other hand, is completely negligible.

Scripts generally don't slow down the server's FPS. The only way to lower the server FPS is to spam it with commands that do things that are CPU intensive. ex: createVehicle 1000 times in a fast loop, or using nearObjects with a large radius (though if you only use it once every 30 minutes, or only a couple times during mission initialization, again you shouldn't have problems, especially if the radius isn't enourmous). Getting a lot of AI units to move around can also cause the server to lose some FPS, but that's really the AI moving around and not the actual script.

Overall, even if you write down 100 infinite loops that just run in the background and do nothing, you're still not going to see an FPS drops. Sure, other scripts won't get nearly as much time to run and would feel "lagged", so it's still a very bad thing to do, but the server FPS should stay intact.

[Double Doppler 10]

Thanks.

Now a question on "for loops":

Would the following loop:

{
   _x setdamage 1;
} forEach units player

Have any difference in performance to the next loop?

for "_i" from 0 to (count (units player ) -1) do {
   _squadmember = (units player) select _i;
   _squadmember setdamage 1;
};

I have read about the C++ style iteration loop as well:

for [{_i=0},{_i<count (units player)},{_i=_i+1} do {...

but discarded use of it since apparently it is slower than the above loops (according to this BIKI link).

Edited February 20, 2012 by Double Doppler

[shuko 59]

Have any difference in performance to the next loop?

....(according to this BIKI link).

You link a BIKI page, but then ask a question that is already answered on the page? ;)

"...are identical in speed (+/- 10%)"

Besides, it matters more what you do inside the loop.