Benchmark Request

[puffdragon]

If some could benchmark these two...

I really wonder if (1 unit, 1 trigger) is better or worse than (1 trigger, 1 event).

call TriggerRegisterUnitEvent(SingleTrigger, Unit[count], EVENT_UNIT_XXX)

VS

call TriggerRegisterUnitEvent(TriggerArr[count], Unit[count], EVENT_UNIT_XXX)

It can be any EVENT_UNIT, for 300 units (or anything above 100)


TriggerArr[count] gets destroyed or recycled once Unit[count] dies, while SingleTrigger not.

P.S Can also be TriggerHash instead of array

Also wonder if (1 unit, 1 event, 1 trigger, 1 function) is better or worse,

as to create 1 Trigger per Event you want to monitor per Unit -> calling for specific unit, for specific event, specific Function, avoiding operands if/else.

 

[Overfrost]

I think 1 trigger for multiple events is faster, it's kind-of obvious. The only problem about that is, one can't remove a single particular registered event from a trigger, therefore the trigger needs to be recreated in order to clear its registered events.

 

[puffdragon]

@Overfrost but in that case, shouldn't all triggers created in function main be recreated in a given opportunity ?

 

[Overfrost]

@Overfrost but in that case, shouldn't all triggers created in function main be recreated in a given opportunity ?

What do you mean exactly by this?

What I meant was to store each registration, register each event normally under one trigger, and periodically recreate the trigger to remove no-longer-registered events inside it. It's about how this recreation-cycle is handled. Other considerations include separating the triggers based on their event type, and whether to use 1 boolexpr per event-trigger or just insert the user's boolexpr directly.

 

[puffdragon]

For example region events, once it gets triggered and wont be used again for some time, should it be recreated to clear events?

Got an example in jass? Currently am not using boolexpr variables, I directly add Condition(), TriggerAddCondition, cause as far as i know conditions do not leak and neither boolexpr created by Condition().

 

[Overfrost]

For example region events, once it gets triggered and wont be used again for some time, should it be recreated to clear events?

I thought this was about Specific Unit Events which are troublesome. If it definitely will trigger again in the future, then there's no need to do anything on it. If it won't trigger again ever, then destroying the trigger and null-ing its variable is the way to go. Example for this:

• Initializer
  • Events
    • Map initialization
  • Conditions
  • Actions
    • -------- do stuffs --------
    • Custom script: call DestroyTrigger(gg_trg_Initializer)
    • Custom script: set gg_trg_Initializer = null
    • -------- still can do stuffs here, though the trigger is gone, but actions still go as usual --------

If you want to clear events, then it can only be done by recreating the trigger.

 

[puffdragon]

I was asking about unit triggers yes, but I just thought about those region trigger too afterwards.

Am most concern on unit trigger as i mentioned cause units dying will never come back!

 

[Overfrost]

I was asking about unit triggers yes, but I just thought about those region trigger too afterwards.

Am most concern on unit trigger as i mentioned cause units dying will never come back!

Just use Generic Unit Event version of it?

 

[puffdragon]

The map is very demanding, needs to be as optimized as possible

 

[Overfrost]

If it's unique to a certain player, use Player Unit Event. Otherwise use the generic version. It's faster to use generic event and do the usual checks than to create more triggers.

If the map itself is the one that needs to be as optimized as possible then there's no optimization option available from this topic.

However, there's another matter that might be optimize-able. According to this, recursive calls proved to be slower than their non-recursive equivalent. Therefore, the use of textmacros not just as CnP helpers is more than welcome to be added to our coding tools.

On top of the use of textmacros, there's function inlining feature of jasshelper that must not be taken lightly. This feature will help in making nice readable scripts while not making any recursive calls. Just in case you haven't known the full rules of it, function-inlining.

I hate to advertise myself, but if you want some optimization examples, you can take a look at this and this. Notice how I use textmacros abusively, because there's no loss in doing that (except for readability, but it seems you don't care about readability anymore).