looping Which looping technique will be faster? (check the examples)

[thy_ 157]

Just thinking...
 

Which one is faster, generally? Of course, considering the same code into the loopings.

 

TAG_fnc_functionName = {
    // Doc string...
    // Returns nothing.

    params ["_something"];
    private ["_varPrivate1"];

    // code that's need to be checked many, many times...

    // CPU breath:
    sleep 1;
    
    // Restart the function in a new branch:
    [_something] spawn TAG_fnc_functionName;    

    // Return:
    true;
};

true;

 

Or

 

while { _someCondTrue } do {

    // code that's need to be checked many, many times...
  
    // CPU breath:
    sleep 1;
};

 

🧐

[mrcurry 496]

13 hours ago, thy_ said:

Which one is faster, generally? Of course, considering the same code into the loopings.

 

Recursive calls into a new thread to simulate a loop, now I've surely seen it all...

 

Considering that spawn has to create a new scope and register in the scheduler and then wait to be executed, the second approach should be faster. 

 

I can't think of a situation where the first option is faster but you could just test it by measuring diag_tickTime, just make sure in your first example to take the final measurement when the last thread finishes.

 

Personally I would never use the first option unless I have to, mostly cause I find it's less readable and managing variables across multiple iterations would be a pain.

[galzohar 31]

The 1st one is a terrible way to do something like that. You probably won't notice any real performance difference, though, but still it's just bad.

When you want a loop, just write a loop. Normally writing what you actually want is the best way, if it's not faster, at the very least it'll be easier to understand later and fix any bugs or add new functionality.

[thy_ 157]

On 11/1/2023 at 4:29 AM, mrcurry said:

 

Recursive calls into a new thread to simulate a loop, now I've surely seen it all... (...)

 

1 hour ago, galzohar said:

The 1st one is a terrible way to do something like that. You probably won't notice any real performance difference, though, but still it's just bad. (...)

 

The solution was proposed by a respected user in the forum (+3000) so this is why I am using that: to manipulate many different units (including vehicles) working together and executing the same type of movements in the field forever until death. When the function call itself, some small tasks are finished mandatorily in the "old" thread like "cancel a position booking" meanwhile the unit executes the basic movements through the new function thread. You can check this (file on GitHub) function line 4744 where it calls itself in certain specific situations:

 

On 11/1/2023 at 4:29 AM, mrcurry said:

Considering that spawn has to create a new scope and register in the scheduler and then wait to be executed, the second approach should be faster. I can't think of a situation where the first option is faster but you could just test it by measuring diag_tickTime, just make sure in your first example to take the final measurement when the last thread finishes.

 

1 hour ago, galzohar said:

When you want a loop, just write a loop. Normally writing what you actually want is the best way, (...)

 

I got total control over what is been done with each new thread to simulate a loop. My question was about performance. 

 

[galzohar 31]

Spawning new threads obviously has more overhead then a loop condition. Whether that will be measure-able in performance - Hard to say (although t will be crazy if it was faster). But I wouldn't do this regardless...