• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • ✅ Time to vote for the top 3 models! The POLL for Hive's 6th HD Modeling Contest: Mechanical is now open! 📅 Poll close on July 16, 2024! 🔗 Cast your vote now!

Performance difference of having conditions in "Conditions" vs "Actions"

Status
Not open for further replies.
Level 12
Joined
May 16, 2020
Messages
660
Hi guys,

In terms of performance, is there a difference between these two triggers?

  • Spin Web Enter Map
    • Events
      • Unit - A unit enters (Playable map area)
    • Conditions
      • Or - Any (Conditions) are true
        • Conditions
          • (Unit-type of (Triggering unit)) Equal to Spiderite (Level 2
          • (Unit-type of (Triggering unit)) Equal to Spiderling (Level 1)
    • Actions
      • Unit Group - Add (Triggering unit) to SpinWeb_GroupInvisibility


  • Spin Web Enter Map
    • Events
      • Unit - A unit enters (Playable map area)
    • Conditions
    • Actions
      • Set VariableSet Web_Unit = (Triggering unit)
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • Or - Any (Conditions) are true
            • Conditions
              • (Unit-type of Web_Unit) Equal to Spiderite (Level 2
              • (Unit-type of Web_Unit) Equal to Spiderling (Level 1)
        • Then - Actions
          • Unit Group - Add (Triggering unit) to SpinWeb_GroupInvisibility
        • Else - Actions

It probably makes a negligable difference anyhow, but it's something I'm always wondering when adding several "Triggering Unit" instead of a variable in the condition.

Thanks!
 
Level 20
Joined
Apr 12, 2018
Messages
494
Most of the time it's purely for readability purposes, but for some Events it can refer to a unit other than the Triggering Unit (generally the Target of the Event).

As far as being 'efficient' goes I personally prefer readability so the triggers don't look like mumbo jumbo when I look at it again somewhere down the line. If you can't figure out what you made you lose a lot of time trying to figure out your own code.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,233
In JASS placing all the code in a trigger condition function is the fastest since apparently running trigger actions is slower than trigger conditions.

In GUI placing the conditions in the condition block is likely to be slightly faster as it does some more inlining. However, in both cases the auto generated script is highly verbose, often relying on resolving a complex tree of functions. If performance is an issue you will be better off moving to JASS or Lua directly and writing more efficient conditional tests.

For the most part this is not a concern unless performance becomes an issue. When performance is an issue, it is usually the result of specific resource intensive triggers. As such it is usually better to keep your triggers as readable as possible over performance, except for the ones that are resource intensive. Example of resource intensive triggers would be triggers that fire 30 to 60 times per second constantly, that iterate all units on the map frequently, that perform complicated calculations on a large set of data or triggers related to collision testing or movement.
 
Level 4
Joined
Feb 16, 2017
Messages
54
In JASS placing all the code in a trigger condition function is the fastest since apparently running trigger actions is slower than trigger conditions.

In GUI placing the conditions in the condition block is likely to be slightly faster as it does some more inlining. However, in both cases the auto generated script is highly verbose, often relying on resolving a complex tree of functions. If performance is an issue you will be better off moving to JASS or Lua directly and writing more efficient conditional tests.

For the most part this is not a concern unless performance becomes an issue. When performance is an issue, it is usually the result of specific resource intensive triggers. As such it is usually better to keep your triggers as readable as possible over performance, except for the ones that are resource intensive. Example of resource intensive triggers would be triggers that fire 30 to 60 times per second constantly, that iterate all units on the map frequently, that perform complicated calculations on a large set of data or triggers related to collision testing or movement.
If I convert a trigger I made with the GUI to code (after finish with convert to custom text), will it affect performance well?
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,233
If I convert a trigger I made with the GUI to code (after finish with convert to custom text), will it affect performance well?
The performance will be the same unless you manually optimise it, or use an optimising program. The convert to custom text function outputs the exact same script the GUI trigger compiles into on map save. There is no JIT optimising compiler either so what you see is pretty much how the virtual machines run it. Make it simpler and generally it will run faster.
 
Last edited:
Status
Not open for further replies.
Top