GetTriggerUnit vs GetEnteringUnit/GetLeavingUnit

[puffdragon]

Are there any benchmark tests done on the speed comparisons between those natives?

 

[Dr Super Good]

Outside of optimizer design, does it really matter?

GetTriggerUnit is probably faster because it is 1 character shorter so hashes faster.

 

[leandrotp]

Look at the disassembly of GetEnteringUnit:

Hidden

As you can see, all it really does is to call GetTriggerEventId, then check if the event id is either 5 (EVENT_GAME_ENTER_REGION) or 61 (EVENT_UNIT_TARGET_IN_RANGE), then jump to GetTriggerUnit if it is, otherwise return null.

Right below it, there's the dissassembly of GetLeavingUnit, and it's exactly the same thing, with the difference that it checks if the event id is 6 (EVENT_GAME_LEAVE_REGION). This pattern is the same for all GetXXXUnit natives, they just check if the event id is appropriate and return the triggering unit.

So it's obvious that calling GetTriggerUnit directly will always be faster, as you will be skipping this check.

 

[puffdragon]

@leandrotp Forgot to add the GetDyingUnit(), but after reading your post I will assume its all the same.

 

[Dr Super Good]

As you can see, all it really does is to call
GetTriggerEventId

No we cannot see that because we do not have the source code of Warcraft III so no functions in it have names. I am assuming you have just decided to name that function "GetTriggerEventId"?

 

[GhostWolf]

No we cannot see that because we do not have the source code of Warcraft III so no functions in it have names. I am assuming you have just decided to name that function "GetTriggerEventId"?

Did you ever use a debugger? Lots of names are saved. Not that this is relevant to the topic in the first place.

 

[Dr Super Good]

Did you ever use a debugger? Lots of names are saved. Not that this is relevant to the topic in the first place.

Yes I did, and Warcraft III source code did not have lots of internal names saved. Compiled C++ does not need function names and commercial software usually has the debug symbols (containing the machine code to function mapping) removed. I do admit that maybe that has changed since I last tried debugging before the recent updates.

An exception is non-static linked libraries. There function names are needed so that function addresses can be resolved at application launch. Even then only the public API function names are needed, so internal functions will all be anonymous.

 

[puffdragon]

GetSpellAbilityUnit
GetEventTargetUnit
GetConstructingUnit
GetConstructedUnit

Same isn't it? They all are same... like they are 3 "categories"

GetAttacker
GetSpellAbilityUnit
GetTriggerUnit

Rest all seem to be the same, they all seem to trigger on an event anyway, thus GetTriggerUnit. I see no difference between those natives

We need new script optimizer.

 

[WaterKnight]

Though seldom seen, you can add different types of events to the same trigger. Then it might make a semantic difference.

 

[Dr Super Good]

Though seldom seen, you can add different types of events to the same trigger. Then it might make a semantic difference.

A well made optimizing compiler should be able to tell such a case as triggers seldom have events attached to them dynamically and those that do usually only 1 type of event.

 

[puffdragon]

@WaterKnight

It still just is the same unit with more events to "catch" it. Way I see it there is no point using anything other than GetTriggerUnit, and in fact I don't even see the point of having more than 1 trigger per event, unless you wanna use TSA (which you shouldn't anyway) or you wanna stack multiple events that not all will be looking for a triggerunit, but instead GetSpellAbilityUnit etc.

 

[WaterKnight]

Just saying if you have any dynamic TriggerRegisterEvent... or move over also TriggerExecute, Enums and the like since event responses are propagated to sub threads, any dynamic call, the same function may be bound to multiple objects etc., it quickly becomes hard to tell. But of course in the majority of maps, the trigger variables will be final and the setup simple and those that use more advanced stuff are likely to already be aware of the topic. But still, the speed difference seems most miniscule, then you should rather consider substitution by variables. Is the Casting responses (gets overridden) bug still prevalent, by the way?

edit: TSA works per instance, one trigger is still enough.

edit2: I don't know. If you develop a map nowadays, actually the whole API should be cut down/altered if it were not for the countless hacks and most circumventing methods to realize certain features. There are too many dependencies and assumptions that make it hard to offer tools. Wrote some objMod to slk library for performance some months ago but there is so much to consider in detail that the applicant should still know what he/she is doing.