does kill all units at (location) cause more slowness than remove?

alternatively does bring units to (location) cause more as well? what is another option? my work in progress is very laggy when played with more than about 4 ppl

yes
Conditions don't lag (much).

Order, Create, move, remove, kill tend to lag. Pretty much anything with units. The way to avoid lag is if you don't always run the trigger.

alright thank you, and kind of a followup question on how the ai checks triggers: would adding command 1 (probe) for ex as the first condition set the stipulation for the whole trigger, and if they do not have that probe the ai would not check the rest of the conditions? this would stop the cpu from checking all triggers as much and remove this lag if its the way im thinking

To answer your concerns as simply as possible, yes, conditions can cause lag in a map even if the trigger isn't firing. With the right (or wrong) use of Bring conditions for example, you can bring a map to a grinding halt even if the trigger itself isn't firing.

I would like to think it works the way you're thinking it does, checking conditions in order and moving on when it gets to one that's false. To answer your question about Bring vs Command, yes the Bring condition causes more lag than Command does. If you need to check at a specific location there isn't much you can do about it though.

Using too many Bring conditions over too large of an area will start causing what appears to be lag. It is actually a memory leak, caused by the way StarCraft handles the Bring condition. If you run into this issue, there isn't much you can do about it since you clearly need Bring for specific locations.

The first thing you should do is troubleshoot your map. Make a copy of the file, and in the new map, change all the players except yours to Computer. Start game, make sure the lag is still there (if it's being caused by triggers it should still be there, if it's a memory leak from Bring conditions it will definitely be there still).

Once you've verified the lag occurs on this map, start deleting triggers in bunches. Delete the first 100, save. Test it again. If it still lags, delete another 100. Keep doing this until it stops lagging. Now you know the problem is within those 100 triggers. Put the last 100 triggers back (copy from real map, have 2 test maps you alternate between, or however you want to handle this). Now repeat the same process except delete the triggers 20 at a time until it stops lagging. Put the last 20 back.

Continue this process with smaller and smaller intervals until you figure out exactly what's causing it. If you can remove the problematic triggers, or workaround them, then do that. Try to reduce them in number as much as possible.

If you can't afford to remove the triggers, then I would suggest trying what you're already considering, placing a condition in front of the other conditions that is false so it won't check the conditions after it. It's a sound idea based in logic, now you just have to hope that the way SC handles it is similarly logical

Post back after the troubleshooting process and let us know what you found to be the problem.

I remember reading somewhere that trigger conditions are actually handled that way, AND it lags less if you put switches first in the conditions list. I'm not sure why though. Don't quote me on it.

Yes, because switches are the quickest to check. No scanning through locations, just check a binary.

Nice, and yes I did quote you!

Next time I run into this issue, that will make for a very efficient workaround, thanks.

Always order your conditions with the least likely to be met one being on top.

In general, yes, but not really.

You should order by cheapest to most expensive, then in order of likelihood of being false.

Eg if you have a switch that is 50% of the time set to True, and also a bring condition that 95% of the time is going to be false, it is still better to put the switch as the first check, because it is faster to check than the bring condition. By putting the switch check first, only 50 times out of 100 will you bother to execute the slow bring condition, whereas if you put the bring condition first you would then be executing the slow bring condition 100 times out of 100 and the fast switch condition only 5 times out of 100.

Very good explanation, well said. As you stated, since the Bring condition will induce lag regardless of it being true or not, it's best to place it at the end of the list of conditions for the reasons demonstrated in your ending example. Now that I know they are definitely checked in order until one is false, I will be certain to pay as much attention to how I order my conditions as I do to how I order the triggers themselves

Definitely some very good information in this thread

big thanks to all I have done a lot of cleaning up triggers and it has helped smooth the map out a lot, but not 100% yet, but I'm still working on it

also the cpu check was a big help as well as the trig order