Scheduler load percentage for spawned scripts

[Sparker 184]

Hello!

As ARMA's scripts spawned inside the scheduler behave as separate threads, it seems logical to me to have a way to estimate how much percents of total scheduler run time is taken by every spawned script, similar to what a task manager in any OS shows for started processes.

Am I missing something, or is there really no such feature in ARMA?

Thanks!

[austin_medic 109]

It doesn't really work that way in arma. Each script runs one after the other and it will only execute for a maximum of 3 ms before it stops, and will continue on the next simulation cycle until it has completed.

 

There is a profiling build that can give you a general overview of what is going on inside each of the games threads (nothing to do with SQF in particular), but SQF and practically all heavy lifting is done by a single thread. 

[Sparker 184]

9 hours ago, austin_medic said:

It doesn't really work that way in arma. Each script runs one after the other and it will only execute for a maximum of 3 ms before it stops, and will continue on the next simulation cycle until it has completed.

Yes, unless the script has been suspended with waitUntil or sleep. Now, If I have the majority of scripts suspended and a single one running an intense piece of code, the scheduler will mostly spend time executing this script while quickly checking and moving other suspended scripts to the top of the queue. So, I could say that 99% of scheduler's resource is utilized by this single script.

Did I make a mistake anywhere?

Of course a different way to estimate scheduler load is to measure execution time of everything between suspension statements, but it would still be hard to see the whole picture of how multiple scripts run concurrently. What If I have scripts that are made by other authors and I want to see their impact on performance?

Another method I'm aware of is to spawn some script that does something and see how many seconds it takes the script to reach the top of scheduler queue.

It is very strange that such a feature is not built into the game engine, considering that we have some diagnostics functions. I hope it will be implemented in the future.

[code34 248]

Sparker i confirm, it works like this.

 

indeed, you will have to create a tool to calculate the consumption of each scripts during executions. This will, however, have a very limited effect, because there is no suspend command to pause a thread (only terminate). In the end, you will have to reopen the script yourself and add sleep commands, and optimize code with little scope. In alternative solution, you can do as I did with the OO_UNITTEST class and executed the code in unschedule environment to evaluate its execution time but it will remain relative to the power of the machine on which the code is executed.

 

We can not really complain because it's still a very interesting feature that needs to evolve.

 

The problem was the part of developpers that still think that we must used non schedule code (because they prior their code against other), and they cause problems of even greater performance on frame rate.

 

For who are in interested by, i wrote a full fr article on scheduler

http://nestheat.eu/2017/12/25/scheduler/

 

[pierremgi 4737]

Hi code34,

Thanks for your explanation and the interesting link about scheduler. I experienced by the past some "never more running" codes along with remote executions (for hint pictures! I know it's dumb). All worked well at the start of mission, then, after several scripts spawning or despawning units, the same codes failed for clients and even hosted server, probably due to CPU load (i mean scheduler tremendous list).

I assume many people experienced also, while gaming on some  server for many hours, AIs loosing their reactivities and waiting to be killed.

 

But here is my question:

Could you explain the KK's remark at the far end of his tuto here. It seems to be helpful to write some "one line sqs" inside addAction (perhaps EHs too), example:

_this call KK_sqfFunctionIWrote (KK's example). This short sqs calls a bigger sqf script. Well, it seems the scheduler can make the difference between sqs and sqf, but is lured by the calling sqs (so with priority?) for the sqf called code.

It seems to me KK abandoned the Arma forums. So thanks in advance for any reply.

[code34 248]

Hi pierremgi

 

KK executed a SQF script from an SQS script to run it in an unscheduled context. You can do the same thing by this way from anywhere in your SQF script
 

isnil {
	_this call Your_sqfFunction;
};

SQS is deprecated and should not be used anymore. The code in unscheduled context should be very short, simple and without heavy or long loop.

 

Concening the KK code

 

//ingame debug console
[] spawn {
    while {true} do {
        allMissionObjects "";
    };
};
player addAction ["VM", "vm.sqf"];
player addAction ["nonVM", "nonvm.sqs"];

//vm.sqf
_frameNo = diag_frameNo;
_tickTime = diag_tickTime;
for "_i" from 1 to 100 do {
    allMissionObjects "";
};
hint str [diag_frameNo - _frameNo, diag_tickTime - _tickTime];

//nonvm.sqs
_frameNo = diag_frameNo
_tickTime = diag_tickTime
for "_i" from 1 to 100 do {allMissionObjects ""}
hint str [diag_frameNo - _frameNo, diag_tickTime - _tickTime]

Like you can notice he created a spawn loop first which had effect to overloading the scheduler. That s why he had so poor perfomance in schedule context. The unschedule context is always prior to schedule context. So the spawn loop was just delay after the execution of sqs script.

 

 

 

 

 

[pierremgi 4737]

Wow. Thanks for this clear explanation. ça déchire!