Script response time

[gc8 970]

Hi

I'm interested of making a script that reports how fast are all scheduled scripts called (Called not executed). You know the more scripts you have running the slower all scripts run.

Here's my code so far:

 

#define RESP_WAIT 3

 lastResponse = time;
 while { true } do
 {
  sleep RESP_WAIT;
  
  _respTime = time - lastResponse - RESP_WAIT; // Count how big delay there was before this script was called
  
  _respTimeText ctrlSetText format["Script response time: %1 s", _respTime];
  
  lastResponse = time;
  
 };

 

I'm interested to hear what you think about this and what tips you may have.

 

thx!

 

 

Edited February 24, 2019 by gc8
Clarification

[Leopard20 813]

Sleep is not reliable when it comes to script computation time (e.g if the engine is busy the code won't be executed for some time). I recommend using something like:
 

if (time - _lastRun >= 3) then {


_lastRun = time;
};

But again adding this to the above while loop makes no sense, so...dunno.

[gc8 970]

13 hours ago, Leopard20 said:

Sleep is not reliable when it comes to script computation time (e.g if the engine is busy the code won't be executed for some time)

 

That's the whole point. I expect the script to sleep 3 seconds and then continue. The time that goes over the 3 seconds is considered lag 🙂

 

[Leopard20 813]

4 hours ago, gc8 said:

 

That's the whole point. I expect the script to sleep 3 seconds and then continue. The time that goes over the 3 seconds is considered lag 🙂

 

Oh. Right. I think I missed the point! 😉

[pierremgi 4737]

You expect some difference between new time and old time, separated by a single line to execute:

_respTimeText ctrlSetText format["Script response time: %1 s", _respTime];

Not sure you will detect a lag with a such short script. Just the exec time of the line.

[gc8 970]

13 hours ago, pierremgi said:

Not sure you will detect a lag with a such short script. Just the exec time of the line.

 

If there's lot of scripts running in theory the script continue delay should get longer

[pierremgi 4737]

7 hours ago, gc8 said:

 

If there's lot of scripts running in theory the script continue delay should get longer

Distortion time?

[gc8 970]

30 minutes ago, pierremgi said:

Distortion time?

 

Script "pause" time, cant explain it any better 😄

 

[pierremgi 4737]

Ah OK, you want a global "lag" for all the scheduled scripts, not pointing at one specific...

Did you have a tour at https://community.bistudio.com/wiki/diag_activeSQFScripts

I pointed at some of mine, too many repetitive (copied to clipboard). That led to me adding some timer conditions in some while loops.

[gc8 970]

9 minutes ago, pierremgi said:

Ah OK, you want a global "lag" for all the scheduled scripts, not pointing at one specific...

 

Yes 🙂

 

I know the diag_activeSQFScripts command but don't know how that helps with this?

[pierremgi 4737]

If you copyToClipboard str diag_activeSqfScripts, you can see your running scripts. Some of them appear several times with their running line.

It's a kind of picture of your scheduler.

Imho, it's a good way to point at too present scripts. Chase the lowest amount of running scripts. (count diag_activeSQFScript).

With heavy scripts, you can see this amount growing in debug console: 10, 100, 1000.... Reading the diag_activeScripts, you will see some evident repetitions (loop, waitUntil or else) which could be optimized.

[gc8 970]

@pierremgi Right, that's worth to check. But right now I'm interested on the script call delay so I know how much the scripts are lagging behind. And to see from that if optimizations are needed

One of the best/quickers optimizers is the sleep command so that scripts sleep more and dont clog up the scheduler

[pierremgi 4737]

That's an interesting point. In most of my code, I'm using uiSleep (and diag_tickTime), instead of sleep (and time). Now, I'm wondering if It's the best way to do. I saw the advantage for preventing some hanged code when game is paused (SP). But, there are probably some consequences on scheduler. That's not clear on my mind.