[B]Is it nessesary to null a unit variable?

[ironman47]

Is it nessesary to null a unit variable like I did in this trigger? Do unit variables leak?

• ChangeOwner
  • Events
    • Unit - A unit comes within 256.00 of No unit
  • Conditions
    • (Owner of No unit) Not equal to Neutral Passive
  • Actions
    • Set Temp_Unit = (Triggering unit)
    • Wait 7.00 game-time seconds
    • Set TempPoint_1 = (Position of Temp_Unit)
    • Set TempPoint_2 = (Position of No unit)
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • (Distance between TempPoint_1 and TempPoint_2) Less than 256.00
      • Then - Actions
        • Unit - Change ownership of No unit to Neutral Hostile and Change color
        • Trigger - Turn off (This trigger)
      • Else - Actions
        • Set Temp_Unit = No unit
    • Custom script: call RemoveLocation(udg_TempPoint_1)
    • Custom script: call RemoveLocation(udg_TempPoint_2)

If so does the action Set <variable> = No unit in GUI get the job done?

 

[ap0calypse]

You can null them, but it doesn't pay off.

People null local variables because they're created every time the trigger is run - if the trigger runs 100 times, all those variables will still have a value. This results in a lot of garbage due to the nature of locals (they're created anew instead of re-used).
In GUI, however, there can only be 1 value assigned to every variable, and even IF you null it, it will be reset to a value next time it's used.

Well, maybe you can null globals you only use once or twice in your map... still won't affect things that much though.

Local variables: yes, null them.
Global variables: not really, unless you only run that trigger a few times.
And yes: setting it to "No Unit" nulls it.

 

[Dr Super Good]

Only null them if the unit they hold will get removed eventually or if the global will never be reused. The only benifit for nulling them is that it allows the handle index to be recycled after the object it was used for has been removed/destroyed. Logically this is stupid if the global is being reused often as it will regually have its value changed (thus freeing the handle indexes it referenced). If the global will never be reused (once off) then you will have to null it to assure that the index it pointed to can be recycled (if the object ever gets removed that is).

 

[ironman47]

People null local variables because they're created every time the trigger is run - if the trigger runs 100 times, all those variables will still have a value. This results in a lot of garbage due to the nature of locals (they're created anew instead of re-used).

So you can't recycle local variables?

In GUI, however, there can only be 1 value assigned to every variable, and even IF you null it, it will be reset to a value next time it's used.

How could there ever be more than one value for a variable?
What about an array? Is an array a single variable with multiple index handles?
You say if you null it, it will be reset to a value next time it is used. What value? The previous value it had? So it does no good to null it.

I'm just trying to get this.

Only null them if the unit they hold will get removed eventually or if the global will never be reused.

Your saying only null a local unit variable if the unit the variable holds will get removed at some point. Otherwise it does no good.

Well that takes all the fun out of it

 

[ap0calypse]

So you can't recycle local variables?

Indeed, you can't.

How could there ever be more than one value for a variable?

Good question... I said that because basically, a local ACTS like it can have multiple values - but it can't either.
If a trigger with a local variable runs twice in the same instance, there will be 2 variables with another value, but those variables are actually the same (yet they aren't).
Locals are weird to explain xD

So it's like:
In instance 1: local unit u = Unit1
In instance 2: local unit u = Unit2

Note that these instances are run at the same time! So these variables can exist together.
These variables are the same (both unit variables called "u"), yet they have another value.
But these variables cannot be recycled, so instead we null them at the end (else warcraft remembers all of it).

What about an array? Is an array a single variable with multiple index handles?
You say if you null it, it will be reset to a value next time it is used. What value? The previous value it had? So it does no good to null it.

I didn't exactly mean 'reset'.
I mean that if the trigger runs again, the variable will just be set to another value - thus the null wouldn't have done anything.

Like:
global unit udg_u

set udg_u = Unit1
set udg_u = null
set udg_u = Unit2

As you can see, even though you nulled it (the second action), the next time the trigger runs it remembers another value anyway.
So your null has been undone and was pointless.


An array acts the same way as multiple regular variables.
So:
Unit1 = A unit
Unit2 = Another unit

Is the same as:

Unit[1] = A unit
Unit[2] = Another unit

The good thing is that you can use them withing loops etc.
So nulling those has the same effect as nulling regular globals.

Your saying only null a local unit variable if the unit the variable holds will get removed at some point. Otherwise it does no good.

No, he wasn't talking about LOCAL variables, he was talking about GLOBAL ones ^^

Let's say you only need a variable called "TempUnit" for the hero selection system.
Once everyone has chosen his hero, that variable will be pretty much useless (the trigger will never activate again), but it still remembers a unit!
THEN you can null the variable, because you'll never need that data anyway.

I believe that's what he was saying.



I hope you kind-of understood this =D
I hope DSG reads this to pick out the possible mistakes...

 

[Dr Super Good]

The whole reason to null is due to handle index recycling. For safety, it does not reuse an index that is still being referenced by variables otherwise it could start pointing to an object it should not which could cause a fatal error.

When you destroy or remove a handle, it deallocates the memory the object used but still keeps the handle ID that was used to point to it referenced (described above). Inorder for the handle ID to be recycled (used again), it must have no variables referencing it.

To keep track of references, each handle ID has a reference counter. Changing a variable to another value (like null or another existing handle) will decrement (reduce) the reference counter by 1. Allocating a variable to point at that handleID will increase the reference counter by 1. If no variables point at the handle and the handle the ID referenced does not exist, then it recycles the handle ID giving it a chance to reference a new object.

From this, it is easy to see when you need to null globals. Only if the object the handle references will be removed should they be nulled if the global will not be used or is not used often. If the global is constantly having its value changed, then nulling is a waste of time.

The problem with locals is that they do correctly incriment the reference counter for the handle they point to but they do not decriment it when the function ends (and its stack entry is deallocated). The result is a leak to the reference counter of a certain handle which prevents it from every getting recycled. Thus you have to null local handles before the function ends to allow the handle ID to be recycled.

HandleID leaks (from using locals or leaving a global referencing it all the time) cause handle allocation opperations to slow down. The main cause is with using local variables in JASS or some GUI BJ calls which run leaky JASS. Globals generally are so few in number it can hardly be attributed to a poor prreforming map directly.

Some objects never get destroyed or removed, as such recycling them is stupid. Players are such an example, you never need to null them as they are only destroyed when a player is defeated or wins and even then it still remains in existance. Trackables are another example as they can never be removed after creation.