Which is better? Have several timers firing for different jobs, or have one large timer that handles multiple things with a branching IF ELSEIF statement?

[TEMPEST.114]

I'm writing my own 'MIST'/'MOOSE' in native, for learning and specific things the others don't do, and I've got to the point where I have four large - let's say atomic units, each doing their own specific job.

3 of the 4 rely on timers to do things - every 5 - 10 seconds they fire. Now, when they start the repetitive timer depends on what the mission requires, so it's possible not all 3 will be running, or all 3 will. It's also very likely that they won't be kicked off at exactly the same time.

So, the question is - is it better to combine them all into one monolithic timer that has a lot of if / elseif statements to handle all the possibilities, but it will only fire once every 5 - 10 seconds to handle everything that the mission requires....

or...

Is it better that each atomic 'unit' of the script has its own timer doing its own atomic thing and firing independently of the others?

All but one of my squadron fly in VR so performance is of utmost priority. 

Any advice from those that have done this sort of thing before?

Thanks

Edited November 12, 2022 by Elphaba

[dark_wood]

I use multiple timer.scheduleFunction or mist.scheduleFunction (6-7, for example) as needed in each mission, no downside observed - but i always try to optimize them in order to not overload the mission, something like:

--START after 3 minutes // Call function every 30 seconds // end it after 30 minutes
mist.scheduleFunction(activateCsar, {}, timer.getTime() + 180, 30, timer.getTime() + 1800)

Whatever is your approach, I think the secret is to make a lot of tests and tune the scripts to fit your needs

[cfrag]

On 11/12/2022 at 8:41 AM, Elphaba said:

So, the question is - is it better to combine them all into one monolithic timer that has a lot of if / elseif statements to handle all the possibilities, but it will only fire once every 5 - 10 seconds to handle everything that the mission requires....

Not knowing the details of how DCS implements scheduling calls, I wager that it won't make much of a difference - invoking methods doesn't waste many cycles, and if push comes to shove, I'd guess that having one central scheduler/dispatcher (DCS) that invokes directly is more efficient than a decentralized setup with lots of if/elseif branches that adds another invocation at the end (one from dcs main dispatch to your dispatcher, and then from yours to the final method). 

That being said, I feel that trying to shave a few cycles off on invocation is squarely in "premature optimization" territory. Your code is bound to spend orders of magnitude more cycles in the method itself, so if you desperately need to improve performance and can't improve the code itself but try to save some cycles on the way it is invoked, you have pretty much lost already. If, on the other hand you can still optimize the invoked code, don't mess with non-standard invocation schemes as that may force you into suboptimal schemes with minimal return on investment.

Usually, I'd say that you should code first, and then let the profiler point you to the worst offenders. Unfortunately we don't have that option in DCS, so it indeed makes sense to talk about this. So for my money, I'd not worry about invocation at this level (once every few minutes is a negligible amount - to waste or to save), and try to design the code efficiently. In a framework I'm working on, the various modules all schedule an 'update' event once every second. twenty modules doing that has a negligible performance impact. One of the modules, however, needs to iterate all units in the game. That one had impact, and some clever coding on my part (tooting my own horn here ) did significantly improve performance. So it's usually not the invocation that does you in, but what you are doing after you are being invoked. From what I hear other people comment on Lua is that you get a significant boost out of using local tables over global tables, so that's something to remember. Unrolling loops can help sometimes, and spreading the load over time (mist does that in an interesting way when it monitors all objects)

 

Edited November 13, 2022 by cfrag

[TEMPEST.114]

1 minute ago, cfrag said:

Not knowing the details of how DCS implements scheduling calls, I wager that it won't make much of a difference - invoking methods doesn't waste many cycles, and if push comes to shove, I'd guess that having one central scheduler/dispatcher (DCS) that invokes directly is more efficient than a decentralized setup with lots of if/elseif branches that adds another invocation at the end (one from dcs main dispatch to your dispatcher, and then from yours to the final method). 

That being said, I feel that trying to shave a few cycles off on invocation is squarely in "premature optimization" territory. Your code is bound to spend orders of magnitude more cycle in the method itself, so if you desperately need to improve performance and can't improve the code itself but try to save some cycles on the way it is invoked, you have pretty much lost already. If, on the other hand you can still optimize the invoked code, don't mess with non-standard invocation schemes as that may force you into suboptimal schemes with minimal return on investment.

Usually, I'd say that you should code first, and then let the profiler point you to the worst offenders. Unfortunately we don't have that option in DCS, so it indeed makes sense to talk about this. So for my money, I'd not worry about invocation at this level (once every few minutes is a negligible amount - to waste or to save), and try to design the code efficiently. In a framework I'm working on, the various modules all schedule an 'update' event once every second. twenty modules doing that has a negligible performance impact. One of the modules, however, needs to iterate all units in the game. That one had impact, and some clever coding on my part (tooting my own horn here ) did significantly improve performance. So it's usually not the invocation that does you in, but what you are doing after you are being invoked. From what I hear other people comment on Lua is that you get a significant boost out of using local tables over global tables, so that's something to remember. Unrolling loops can help sometimes, and spreading the load over time (mist does that in an interesting way when it monitors all objects)

 

 

Thanks @cfrag I'm aware of that 'premature' problem. I just didn't want to spend a lot of time making individual timers / schedulers and then finding out it's all wasted and I have to reengineer my whole script if others had run into this first. It's certainly easier for me - at the moment - to keep them separate and smaller/atomic. So I'll just go with that.

 

Thanks for your advice.