multiple Generic unit events. optimization?

[ShaDowPoWeR]

so, I have a lot of generic unit events for manipulating items, spells, deaths and attacks. using JASS (converted from GUI)
* Some of these triggers have conditions, some have if then else and some have both.
* Some of these triggers have complex conditions.
What's the most efficient way of handling these generic triggers, should I just merge them all into a single trigger with just if then else or make simple conditions and put them in the conditions part.
for example I have a lot of triggers that affect 3 or 4 unit types when they die for example something like this:

• Untitled Trigger 002 Copy Copy
  • Events
    • Unit - A unit Dies
  • Conditions
    • Or - Any (Conditions) are true
      • Conditions
        • (Unit-type of (Triggering unit)) Equal to Footman
        • (Unit-type of (Triggering unit)) Equal to Knight
        • (Unit-type of (Triggering unit)) Equal to Rifleman
  • Actions
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • Or - Any (Conditions) are true
          • Conditions
            • (Unit-type of (Triggering unit)) Equal to Footman
            • (Unit-type of (Triggering unit)) Equal to Rifleman
            • (Unit-type of (Triggering unit)) Equal to Knight
      • Then - Actions
        • Unit - Set life of (Killing unit) to 5.00
      • Else - Actions

should I just remove the conditions ?
should I just make 1 trigger per unit type and just use conditions instead of if then else ?
also I have a lot of triggers, should I merge them all into the same trigger?
I want to optimize the performance but I don't know the best way to proceed, I have removed a lot of memory leaks but there is still a lot of inefficient code.

(btw using an optimizer + some scripts I made I have optimized the script a lot so it isn't as bad as the stuff you get from converting from gui to jass)

 

[Jampion]

If you have multiple triggers with the same condition it is better to merge them, so the condition is only checked once.
If you really have a lot of unit type conditions, you could use a hashtable to map unit type to triggers or use binary search (unit type is an integer).
The hasthable thing works well for abilities: You use spell ability id as key, so you don't have to check every ability id.
Specific unit events could make work as well, if the event only affects very few units.
But this is a lot of work and will make code less readable. You have to decide if it is worth it.

 

[ShaDowPoWeR]

mmm I don't know, the thing with hashtables is that it doesn't work with older versions so I just avoid it, though I make a separate version for 1.29+.

 

[BloodSoul]

Are you supporting warcraft III versions older than 1.24?

 

[ShaDowPoWeR]

just 1.24+ though, I'm not using very complicated stuff so idk if it works in older versions.

 

[Dr Super Good]

Hash tables are pretty ancient by now...

Merging into 1 trigger is an optimization. Using a hashtable or lookup tree, as suggested above, is another. Chances are neither optimization is needed unless dozens of units are dying every game frame which would point towards bad map design.

 

[ShaDowPoWeR]

testing a bit more, I've found that the damage system is the thing that's causing the most lag (tried creating 100 units vs multiple units with 1 damage + cleave = 0 fps) though death triggers still generate some lag (because a lot of units die and respawn). I might have to think if I truly need the damage system...

 

[Dr Super Good]

though death triggers still generate some lag (because a lot of units die and respawn)

It is more likely the "respawn" creating the lag rather than the death. The unit displacer used by normal moving or creating a unit with triggers is very resource intensive. Either that or you run a lot of code (like a thousand lines of JASS or more) every time a unit dies.

I might have to think if I truly need the damage system...

Make sure it is not how you are using the damage detection system that is causing the problems. The overhead of a damage detection system should be some linear function of the number of times any unit takes damage. I do not think having several thousand cases of damage per second would be a problem for a damage detection system performance wise.

On the other hand the damage detection system will execute your code every time a unit takes damage. If your code is inefficient or resource heavy then it might be a problem.

Equally well Warcraft III will just perform badly if you make it do stupid things. For example making a unit attack 50 times per second (yes this is possible) with a 20,000 area cleave against 500 units will make the frame rate tank to unresponsive levels even without any triggers. Units with area damage, cleave or piercing shots should attack slowly, more so than units without. Unit numbers should also be kept reasonable, for example average of 48 or so units per player max.