• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

Which is Faster or Better

Status
Not open for further replies.
Between these functions, which function is faster or better to use? These functions are called in a fast periodic timer, inside of a loop.
JASS:
globals
    trigger array   Triggers
endglobals

function Function_1 takes integer Index returns nothing
    call TriggerEvaluate(Triggers[Index])
endfunction

function Function_2 takes integer Index returns nothing
    local trigger Trigger=Triggers[Index]
    if(Trigger!=null)then
        call TriggerEvaluate(Trigger)
    endif
    set Trigger=null
endfunction

function Function_3 takes integer Index returns nothing
    if(Triggers[Index]!=null)then
        call TriggerEvaluate(Triggers[Index])
    endif
endfunction
 
Level 15
Joined
Aug 7, 2013
Messages
1,338
Chaosy said:
function 1 x)

I believe Function_1 is the fastest, like Chaosy. Just assume that the client won't pass in an index which points to a null member in the trigger array and you could keep this one.

Function_2: There's a local variable, an if statement, and then sets the local variable to null.

Function_3: The array is being accessed twice for a value that could be cached.

I'd put my money on Function_1, though I don't know if array access is cheaper than using a local variable (i.e. which of Function_2 and Function_3 is faster).

P.S. Which do you think is fastest Zeatherann? If I recall correctly you're also a game developer / programmer outside of the hive.
 
Function 1 seems ok, if you can ensure the variable has a correct value.
There is also no problem to use function 3, if you can't.
I would not go with function 2, but actually there is also not really a problem with it.

Things like this is not really worth to ask for, there are more important things than discussing about one if != null check more or less. :/
 
Function_1 > Function_3 > Function_2

However, there might be situations where you want to use any of them.
Function_2 might be usefull when responding to an event to retrieve e.g unit id (your index) and then proceed accordingly with trigger.
If you want safety and debug msg - you will prefer options 2/3, thus providing healthy information to a user if need be.
In regard to safety - sometimes it's better to check if the scalar is valid to prevent unnecessary operations to take place.

Again, if you just care about effectiveness and possible inlining, take the option 1. If you want to provide additional info/safety - choose 2/3 (don't bash me, I know that in this case, safety is not required).
Now let's be real, functions with declaration like yours, are unlikely to happen - why I say that? - because the only thing presented variants do is evaluation of trigger given the index. It is not a good design - you are creating "BJs" yourself.

Most of the time, as stated above, such operation are preceded with event handling and retrieval of info to access our "index", thus you can implement such directly within other functions :)
 
Function 1. Take advantage of the fact that many Blizzard natives already perform checks for null cases (either that or it just does nothing). The internal code will almost always be faster than the JASS equivalent. You usually only need those checks for error-reporting or when it changes what you'll do in the function.
 
Most of my knowledge is thrown off track when it comes to JASS, Blizzard is wierd sometimes. I feelFunction_1is the fastest. There will be (sometimes common) cases of the trigger at the given index being null however.TriggerEvaluate()does handle null cases though (no map/thread crash). I had suspected that the first function was the best option, but I wanted to check for your guys' opinions.Thank you all!
 
Status
Not open for further replies.
Top