- Joined
- Nov 11, 2006
- Messages
- 7,651
People are biting at straws in this thread. So what if one method is 30% slower than the other? In most maps there are bigger fish to fry.
Has anyone actually benchmarked how much wasted time all those trigger evaluations cause when a custom ability is cast? The common way of doing a fully MUI custom ability is a any unit begins effect event followed by some kind of test to kill the thread if the wrong ability is cast. This is fine for 1, 2 and even 5 abilities but some maps have dozens of custom abilities doing this. The overhead of evaluating custom abilities is thus O(n) per cast where n is the number in the map. This technically means a map with hundreds of custom abilities would have a pretty huge overhead per ability cast just to check if it was the correct ability being cast. Worse is these evaluations apply to even non-triggered abilities as they still are tested if they are triggered.
So the solution? Well two spring to mind...
1. Use a single ability cast system that registers functions and the ability to trigger them. When an ability is cast by a unit it then performs a hashtable lookup for the ability function. If none exists then it was not a triggered ability and nothing happens. If one exists then it evaluates it. This results in a O(1) overhead no mater how many triggered abilities are registered.
2. Only register units which have the ability to the ability trigger using a specific unit event. This still results in O(n) tests but n is only the triggered abilities that the specific unit has so is considerably smaller and a non-issue. The system needs to manage removed units to be MUI so that adds some additional overhead. The advantage of this approach is no tests for units that do not have triggered abilities at all.
The potential savings is small but I imagine it will add up over time. Especially seeing how each evaluation creates a separate trigger thread.
Yep. That led to the creation of systems like RegisterPlayerUnitEvent, SpellEffectEvent, OrderEvent, GTrigger, etc.
Although, I don't think it needs a benchmark. Complexity wise it is clearly superior.
P.S. I like those idioms in your post (biting at straws, bigger fish to fry).