Order of trigger conditions and performance

[RKurtzDmitriyev]

I'd be interested to know if triggers will cause varying amounts of lag according to the order of their conditions.

For example, suppose I have a trigger of type "West present." Suppose that, most of the time, there will be no West units in the trigger radius. Will the following two trigger condition sets cause the same amount of lag?

Conditions:

Code: [Select]

this && alive player
Conditions:

Code: [Select]

alive player && this
The value "this" will return false most of the time. In that case, no matter whether the player is alive, the trigger conditions cannot be true as a whole. Perhaps, then, the engine saves time by ignoring the second part of the conditions. This will reduce lag, because it can move on to whatever it's supposed to do next.

On the other hand, the player will almost certainly be alive most of the time, so with the second trigger, the engine will be forced to check the other condition as well.

So it seems that the first condition may be less laggy. But perhaps the engine cannot save time by ignoring the rest of the conditions line when the line cannot be true. Does anyone know? This may be useful for improving performance.

Thanks.

[Krieg]

I do not think that order of conditions will do anything.
It will have same effect, just perhaps a very slight delay in checking the condition.

[dr. seltsam]

Good question... I would like to know that for myself..
I think the complexity of a partial condition is also a factor for the performance. A possible way to verify your theory would be to set up a test mission, then place your first trigger on the map, use copy and paste to multiplicate this trigger over and over again, maybe 100 or 1000 times. Do this to the point where you clearly notice lag when playing the test mission. Keep the number of placed triggers in your mind. Then do the same with the other trigger type, place the same amount, and check for a difference. Tell us your results here.

[RKurtzDmitriyev]

So I'll probably get around to testing this eventually, I guess it wasn't too high on my list of things to do. Stay tuned, though.

EDIT: Well, I'm trying to cut-and-paste enough triggers to cause lag, but I've tried putting in over 2000 "detected by" triggers and I can't get it to lag! Why can't lag show up if and only if you want it to?  As I add triggers it's lagging the mission editor (with all those icons) much faster than the mission itself! Stay tuned. 

[savedbygrace]

The type of conditional checks do not matter. It is the execution of the code which places such high demand on the processor. Each trigger is checked twice a second and thus placing them will not induce the lag. But if several of those trigger conditions are met at once OR you have several looping scripts which execute code at the same time, lag will become evident.

The lag you are experiencing from the amount of triggers placed in the editor is probably a graphics processor problem from having to regenerate all of those icons every time you move the screen. That same lag does not show in game because the images of the triggers do not show.

[RKurtzDmitriyev]

The type of conditional checks do not matter. It is the execution of the code which places such high demand on the processor. Each trigger is checked twice a second and thus placing them will not induce the lag.

So, in other words, the engine can check triggers almost instantaneously, much faster than it can execute them? This seems to contradict what I read elsewhere.

Maybe I'll try placing thousands of triggers with complex conditions rather than "this." Macguba in the thread above says that those poll much faster than twice/second.

[savedbygrace]

No, I do not debate that triggers poll every 0.5 seconds. I am saying that there is no strain on the amount of triggers that have to poll every 0.5 seconds. Checking for conditions is the same as reading code, it is blazing fast. But when the processor has to execute the code afterwards, it has to access, blocks of code from various other files or resources or what have you which effects the overall speed of the processing. Each execution adds one more level of slow down and thus the more that is executed at once, the slower your processor becomes. The more RAM you have the more information your processor can store for quicker access, which is like grabbing a tool from your toolbelt rather than having to dig through your tool box to look for it.

Trigger execution certainly has a profound effect on processor speed, though simply reading through the conditions do not.