- Joined
- Jul 10, 2008
- Messages
- 353
Are there any benchmark tests done on the speed comparisons between those natives?
GetEnteringUnit
: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.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.GetTriggerUnit
directly will always be faster, as you will be skipping this check.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"?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"?
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.Did you ever use a debugger? Lots of names are saved. Not that this is relevant to the topic in the first place.
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.Though seldom seen, you can add different types of events to the same trigger. Then it might make a semantic difference.