Bug #8897

3rd party 0.03ms script scheduling (Script lag)

Added by DMarkwick over 5 years ago. Updated about 5 years ago.

Status:Expired Start date:02/07/2010
Priority:Normal Due date:
Assignee:- % Done:


Category:Performance breakdown
Target version:-
Affected ArmA II version:1.05.62017 First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:No NGUrl:
Related to content of DLC: WIKIurl:


Fist - apologies if this issue already exists under a different description. I searched, but I only know my own name for this effect :)

I'm sure plenty of people have experienced this: you perform an action, trip a trigger that calls a script, something that requires 3rd party sripts to run, and you don't see any result for up to several seconds. I am led to believe this is the result of the 0.03ms time limit that the A2 engine puts on 3rd party scripts to run, and if they haven't made the line then they're scheduled for the next cycle.

Now, obviously, a delay of one or two frames (cycles) is negligible, so there is possibly something wrong with the script scheduling system.

By way of a visual example I have an addon that places up to several hundred particle emitters around the game map, but only emitters close to the player emit. The others sleep then test for player distance (< 50m) on a cycle. The emitters that DO emit due to closeness however (and mostly there are only a very few, 3 or 4 say), sometimes they simply stop, or are very intermittent, or some combination of stopping & restarting with unreliable results. I believe this effect is the result of inefficient script scheduling, for even with several hundred scripts running at a time, most are asleep (although probably constantly monitored) but even so I wouldn't expect a running emitter script to be non-emissive for several seconds. Sometimes as many as 15 or 20 seconds.

No other mods running BTW. But obviously, when lots of mods are running, this script-lag can mount up seriously. I believe lots of small events are being delayed more than necessary because of this.

JTD_ACTON_01e.7z - JTD Ambient Civilian Traffic Module - 01e (15.8 kB) Trexian, 02/11/2010 20:30


Updated by kju over 5 years ago

  • Due date set to 02/14/2010
  • Status changed from New to Feedback
  • Target version deleted (1.00.57270)

Very unlikely to be inefficient. Otherwise too many other things would not work.
It is very likely a design problem in your scripts.


a) We need a (simple) repro.
b) Did you let people review your scripts?
c) Did you measure execution delay with diag_tick?

Updated by DMarkwick over 5 years ago

Well, by way of repro I have a simple addAction script that all it does is createCam at the player's position, nothing else, so I can at any time float off & watch my test scenarios in a controlled way. When there is a lot of action going on (DAC demo + Fire & Smoke + ACE2 say) I can trip the Action, then wait 6 or 7 seconds before I get the camera.

By way of another example, during a similarly heavy session I can run up to a wall, then spend several seconds trying to use ACE2's Shift+Spacebar to rest my weapon on the wall. Using the keypresses, repeating the keypresses, and holding the keypresses results in a similar delay. It's usually the case that if I need to run up to a wall and immediately rest my weapon on it, that I don't have those several seconds to spare :)

But those are just 2 simple examples that are easily shown, I'm sure that there is a LOT of stuff that is being similarly delayed that the player won't necessarily pick up on, because they aren't visual.

Updated by Rommel over 5 years ago

How much do you have running!
I had to get around over 7,000 simple loops to get a 3 second delay, for it to be in the 20second delay, you must have... well do the math (67,000 simple loops at perfect cycle rate, assume 75%, 50,000 simple loops). I have tested this data before, and it is correct***.
One of two options to you:

a) Your computer sucks and can't handle very simple scripting (fyi your GPU is better mine, and your CPU within a similar range)
b) Your functions are very complex and should be bench marked for performance

Option (A) Extended.

Option (B) Extended.

Hope this helps.

Updated by DMarkwick over 5 years ago

Rommel wrote:

How much do you have running!
I had to get around over 7,000 simple loops to get a 3 second delay, for it to be in the 20second delay, you must have... well do the math (67,000 simple loops at perfect cycle rate, assume 75%, 50,000 simple loops). I have tested this data before, and it is correct***.

Well the reason I might suspect an inefficiency in the scheduling system is that it is rather variable. In the emitter example in the OP, I see very variable performance while watching one single emitter. Sometimes it seems to function reasonably (I expect some amount of slowdown after maybe a half-hour of dropping emitters ;)) but sometimes it just... stops, restarts, is very stop-starty, some combination. That's just the most visual example as I say.

I will take a look at that CBA function benchmark thingy.

Updated by kju over 5 years ago

What code are we talking here DMarkwick?

Updated by DMarkwick over 5 years ago

kju wrote:

What code are we talking here DMarkwick?

Well I don't think the specific code I refer to is too important, as I also see the behavior when I disable ALL my own stuff. It's just that I refer to it because most of my stuff is very visual and it clues me in to the issue sooner. As a repro example though I can still refer you to the Shift+Spacebar resting-the-rifle-on-the-wall behavior when the situation is very busy. Or indeed you can simply make an addAction for yourself that runs a script which creates a camera at your position, then using it when things are very busy. In both cases you will see delays of 3-4 seconds, which although not sounding like a lot does sound to me like some scheduling problem taken in the context of a 20FPS game session. That's 60-80 "missed" cycles which sounds like a lot to me.

However, if you insist on seeing the code, I can easily post it up. It's just a looped emitter that checks for player distance, and either rests for 10 seconds if player is too far away or emits for 10 seconds before repeating the distance check.
It seems to work fine until a certain level of ingame complexity is met, then it starts to break down. I might suspect this certain level of complexity to equal the time when all scripts running add up to over 0.3ms. But that is speculation, hence this ticket.

Updated by kju over 5 years ago

Well a ticket needs facts and reproduction.
Otherwise it is not useful unfortunately.

I am insisting on more information as your experience is contrary to
everyone else experience here.

At the same time if you design scripts very badly in terms of performance
of course a lot of bad things can happen (most prominent before a2 - game freeze).

Updated by DMarkwick over 5 years ago

OK, if it's not enough merely to give two specific examples by description I guess I will need to supply explicit example by file.


That file contains 3 things: one, a mission with nothing going on. Two, a mission with lots going on. Three, a simple camera spawn addon.

Now, in both scenarios, run ACE2 and anything else you fancy so that the 3rd party scripts are sure to exceed the 0.3ms limit. The busy scenario will be busy from the start, however you can also wait a couple of minutes for it all to really kick off too.

In both missions, do these two things.
One. Go up to the wall in front of you and use Shift+Spacebar to rest your weapon on the wall.
Two. Use the Action menu and spawn a camera at your position.

In the non-busy version, I get almost instantaneous activity. I can rest my weapon on the wall with no delay, and I can instantly spawn a camera on my position. On my game settings I get a steady 20 FPS on this.

In the busy version, I get between 5 and 10 FPS, and I get a 20 second delay for the weapon on the wall action, followed by another 10 seconds before I get the text affirmation. Similarly I get a 15-20 second delay when I try to spawn a camera at my position using the Action menu.

I note however that all ingame "natural" actions are still almost instantaneous, which is expected as they are not subject to the 0.3ms limitation of execution.

Also please note that other than the very simple camera spawning addon, I am NOT running any other JTD product, so my implied very inefficient scripts are not the problem here :)

If "everyone else here" does NOT see large delays in these two actions, I will be very surprised. To be clear: I would expect some amount of slowdown, given that my framerates drop by 50-75%, and I expect individual results to be variable due to variables in performance balance, however I still believe, by the observation of the huge implied script delays in this example, that scheduling is somewhat amiss.

Updated by kju over 5 years ago

I cannot confirm your experience.

1 test:
60 FPS steady. Change to cam instant.

2 test:
10 FPS at start, 20 FPS after 30 seconds.
Change to cam with a delay of ~0.5 sec or less.

Your 2nd scenario is a duplicate of this bug: #6963
That is basically completely unrelated to the script scheduling.

For the record. A valid CIT report needs:

Observed behavior, vs expected in short words.
In addition a reproduction steps and best a demo mission.
No addons may be used in the process.

See the CIT wiki guide.

Updated by DMarkwick over 5 years ago

I think an issue that observes the scheduling of addons requires that addons be used. I cannot see a way around that one :)

Updated by kju over 5 years ago

Latest ACE2, CBA used.

Scheduling can be easily created by scripting only.
Using many many AI groups or "addons" has little relation to the suggested problem.

Updated by DMarkwick over 5 years ago

kju wrote:

Latest ACE2, CBA used.

Scheduling can be easily created by scripting.

I don't understand what you're telling me with that.

Using many many AI groups or "addons" has little relation to the suggested problem.

Well now I'm confused, how can the use of many addons across many units not be related to the issue of addon scheduling?

Updated by kju over 5 years ago

Addon scheduling?

There is only script scheduling. Do you mean that?

Updated by DMarkwick over 5 years ago

I see. Yes. I mean script scheduling, and I use the word addon because that's where they all are. And I use lots of units in lots of groups with AI addons like ACE2, VFAI etc to make sure that a lot of scripts are running. When all the action kicks off, with all the extra combat scripting and suchlike, a lot of 3rd party scripts will be running.

Updated by Trexian over 5 years ago

Heya, yeah... uh... I've seen this, too. :)

Grab the JTD_Camera pbo from DM's previous post. It isn't absolutely necessary, but can give you a perceivable event to time from.

Go in Chernarus and create a SP mission in any city - preferably a decent sized one. Preview it and see what the delay is between selecting the camera action and it starting. Now, place ALICE and SILVIE modules in the map, and preview it again, and notice the delay. For additional slow-down, grab my civilian traffic module:
http://www.mediafire.com/file/moy5e2zmz0h/JTD_ACTON_01e.7z (also attached)

And preview the mission again. For me, there is a delay of a few seconds between hitting the addaction for the camera, and the actual start of the camera.

There isn't really even any "action." Just a bunch of math process determining random positions and spawning stuff. Well, I guess that is "action" just not stuff shooting or blowing up.

Updated by kju over 5 years ago

From looking at your script it seems to have the same source.
You create a lot of groups with AI (single unit, but doesn't matter) (max 50).

These in addition to the ones created by SILVIE and ALICE probably result
again in #6963.

Updated by Trexian over 5 years ago

Pardon my lack of ability to follow you, but I don't understand the connection.

If I understand correctly, you agree there is a scheduling issue, and assert that the spawning of AI is given precedence over the running of scripts.

Regardless, once the AI has spawned, and the issue has more to do with shooting and exploding, then there should be no 'script-lag' because AI are not being spawned at that point.

Updated by kju over 5 years ago

No I dont see a scheduling issue.

ArmA II appears to have an issue with more than 100 groups created as shown in the other ticket.
It is not about spawning moment, it is about the amount of AI groups in a mission.

Read the other issue. I have linked it for a purpose.

Updated by DMarkwick over 5 years ago

So is there any theory why I would see zero delay in selecting weapons, dropping items, entering ammo crates, all the "natural" actions, but that I get a 20 second delay in resting a weapon or spawning a camera, both script-based actions?

Updated by DMarkwick over 5 years ago

Right, a little more information. I just ran the stress mission again several times, with addons and without addons.

Both times, the framerates were approximately the same (5-10FPS). Without addons, I can spawn a camera within one second, just as you say KJU. With addons (ACE2, VFAI, other AI enhancement addons) I get a 15-20 second delay on spawning a camera.

KJU, are you sure you did the test correctly, with ACE2, VFAI and any other AI addon/scripts running? Because that is the crux of the issue, the scheduling of all those running scripts.

Without addons, instant spawn of camera despite very low FPS.
With addons, ~15 seconds delay on spawning a camera.

And when I say addons, I of course mean addons that run scripts on units, like ACE2. All those scripts running on all those units seems to be causing the 0.3ms limit to be breached, and once that is breached, variable script scheduling is apparent.

Updated by kju about 5 years ago

  • Due date deleted (02/14/2010)
  • Status changed from Feedback to Expired

Also available in: Atom PDF