Location Leak question

[Neversleeping]

On the tutorials I've read, they always say I should use
call RemoveLocation (udg_Temp_Point). But is that necessary, if I always use that variable anyway? I mean, when I set Temp_Point to somewhere else, won't it overwrite the memory allocation using it, instead of piling up?

 

[Maximilianx]

It will pile up, always remove the location before making a change to the variable, else it will leak.

Although you don't have to RemoveLocation() if you're not changing the variable.

 

[Neversleeping]

Thanks.

And if I select (unit group) all units in a empty region (so no units are actually selected), will that trigger leak?

 

[baassee]

It will set it self as no units is inside the group and if you set it different after, leak.

 

[Adiktuz]

here's how it works...

setting the variable to a value(A) will make you able to easily call that value
then if you set the variable again to another value(B) then you will not be able to reference (A) again and it will stay there and take up memory and so if you don't need (A) anymore that will be called a leak...

 

[Berb]

There is a function called MoveLocation that helps a lot when you only want to have 1 location at a time. What it does is allow you to create a location at map initialization (0, 0) and then use it by moving it around. This saves you the trouble of removing it after using it, and you don't have to constantly create new ones.

native MoveLocation takes location whichLocation, real newX, real newY returns nothing

 

[baassee]

or you just skip using locations and use coordinates instead but that's more of a vJass thingie

 

[Hemlock]

Well to narrow it down for you, you don't need to remove variable content, when the content doesn't change.

 

[Berb]

or you just skip using locations and use coordinates instead

Locations have their purposes. It may be faster to use coordinate reals instead of locations but certain functions only have location parameters, with no x/y equivalent. For instance, the function GetLocationZ has no x/y equivalent yet it is used constantly in code.

In this situation, it would be far more efficient to have one global location variable that you move around, rather than creating/destroying a handle every time you want to use that function.

globals
    private location g_tempLoc = Location(0, 0)
endglobals
...
...
    call MoveLocation(g_tempLoc, someX, someY)
    set someZ = GetLocationZ(g_tempLoc)
...

This is much better than:

...
    set tempLoc = Location( someX, someY )
    set someZ = GetLocationZ(tempLoc)
    call RemoveLocation(tempLoc)
    // if it were a local location, you'd want to be sure to null it as well.
...

 

[Darkness-4ever]

Locations have their purposes. It may be faster to use coordinate reals instead of locations but certain functions only have location parameters, with no x/y equivalent. For instance, the function GetLocationZ has no x/y equivalent yet it is used constantly in code.

In this situation, it would be far more efficient to have one global location variable that you move around, rather than creating/destroying a handle every time you want to use that function.

globals
    private location g_tempLoc = Location(0, 0)
endglobals
...
...
    call MoveLocation(g_tempLoc, someX, someY)
    set someZ = GetLocationZ(g_tempLoc)
...

This is much better than:

...
    set tempLoc = Location( someX, someY )
    set someZ = GetLocationZ(tempLoc)
    call RemoveLocation(tempLoc)
    // if it were a local location, you'd want to be sure to null it as well.
...

And I learned something new, thought that moving MoveLocation was just another way of creating them, but apparently its more efficient when concerned with the Z values.

 

[PurgeandFire]

It is fine to use one location and move it around if your map warrants it, but to answer your question, yeah it does leak every time you renew the location it is. Think of it this way: You are creating a handle. The variable merely represents that handle. Renewing what the variable represents means that the handle is still there, and is still a leak since it wasn't destroyed.

There are ways to fix this if you want one variable. First method is Berbanog's way, and the other method is removing the location each time. Just because you remove it doesn't mean that the variable is void and unusable. You can still use the variable and it'll function properly. The only thing about one global variable is that you'll most likely lose MUI. If two triggers happen to run at one time and they both use Temp_Loc, it'll probably get overwritten and be overall troublesome.

The whole moving-location technique does still leak a location the entire time, but you won't notice it even if you'd played for 10 hours straight.

The reason why coordinates are preferred more than locations though, is because it doesn't leak any memory and it is compatible with more JASS natives. But Berbanog's overall point, the fact that locations do have purposes, is true.

 

[Berb]

First method is Berbanog's way, and the other method is removing the location each time.

I believe both of those were my methods

If two triggers happen to run at one time

This can't happen. Everything you do in the World Editor is executed on a single thread (or something like that), which basically boils down to only one piece of code being executed at any specific time. For example, if you have 2 timers that expire in 0.00 seconds (and respond with different functions) it will be clear each time which function executed first. They will never be executed at the same time.

moving-location technique does still leak a location the entire time

No because you don't lose reference to it. Its a global variable.

 

[PurgeandFire]

This can't happen. Everything you do in the World Editor is executed on a single thread (or something like that), which basically boils down to only one piece of code being executed at any specific time. For example, if you have 2 timers that expire in 0.00 seconds (and respond with different functions) it will be clear each time which function executed first. They will never be executed at the same time.

I'm sorry, I misphrased it. I should've said triggers that deal with a timer/wait. Since many projectile-related/sliding spells usually use the previous value of Temp_Loc and add to it, another trigger could change the value within the timer duration and alter its effects. Or if generally two people casted that spell at similar times in different areas.

No because you don't lose reference to it. Its a global variable.

Since when does referencing deal with memory leaks? The fact of the matter is that a handle is being created. =P Not to be nit-picky, but it is still a leak. The location is still there. If 20,000 locations were made and ran constantly throughout the game, with each an individual variable for the location, it would still leak. Yeah, you'd have reference for it in each global variable, but it is the matter of creating 20,000 handles that causes the leak. Losing reference to it just makes it so that you can't really remove the leak unless you have some way to retrieve it again.

This is a much smaller case though and no performance will be noticed. Just clearing things up so people don't misinterpret some things.

 

[Berb]

use the previous value of Temp_Loc and add to it, another trigger could change the value within the timer duration and alter its effects

This is the same for any global variable, not just locations. Say for example you're trying to knock back a specific unit and you save it as a global variable. If you change the unit then it will cause the knock back to malfunction.

Since when does referencing deal with memory leaks?

A memory leak occurs when you lose reference to a certain block of memory. If you don't lose reference to it then its not considered a "leak".

The fact of the matter is that a handle is being created. =P Not to be nit-picky, but it is still a leak.

You can't consider a memory leak as any handle that's been created. Click here for more information on memory leaks.

Losing reference to it just makes it so that you can't really remove the leak

Your understanding of memory leaks is a little bleak.

Just clearing things up so people don't misinterpret some things.

Its funny because you're the one misinterpreting.

But is that necessary, if I always use that variable anyway? I mean, when I set Temp_Point to somewhere else, won't it overwrite the memory allocation using it, instead of piling up?

Back to the point, it is very necessary. The location variable is not what you should be worrying about, especially if its a global. What the memory leak concerns is the object which the location variable is referencing. If you change the reference so that the object is no longer being referenced, then how exactly do you plan on removing the object later (hint, you can't).

 

[PurgeandFire]

This is the same for any global variable, not just locations. Say for example you're trying to knock back a specific unit and you save it as a global variable. If you change the unit then it will cause the knock back to malfunction.

Yes but that isn't the point I was trying to make. :\ All I was intentionally trying to say is that using one global has a higher risk of losing MUI than using several globals since you'll have more triggers that deal with the lone variable, which will give it a higher chance of being overwritten. (Not necessarily though, since you might have only timers/waits used in a lone trigger/spell, so it is situational.)

A memory leak occurs when you lose reference to a certain block of memory. If you don't lose reference to it then its not considered a "leak".

Unwanted memory consumption seems more like a "leak" to me. When a handle is created, it is using up memory. In that stage, it is considered a leak. When the handle is removed or destroyed, then the leak will be fixed since it is no longer using up memory.

You can't consider a memory leak as any handle that's been created. Click here for more information on memory leaks.

Creating handles in wc3 is the source of memory usage. So I think it is fair to say that they cause the leaks trigger-wise.

When you lose reference to a handle, yeah it is a leak. But it didn't go from not a leak to a leak just from losing reference. It would be called a reference leak or something odd like that if that were the case. =D If simply "not losing reference" to handles were the source of our leak fixes, then that would imply that we could create several handles assigned to global variables, and just leave them there as long as it was a one-time-only trigger, even if we never use the data again.

Although, you are right as to the location not being necessarily a "leak" since it is intentional... =D

 

[Berb]

Okay you're right. Whatever you want to hear.

But it didn't go from not a leak to a leak just from losing reference.

Did you even read the link I sent you? This is the very first sentence:

"A memory leak or leakage in computer science is a particular type of memory consumption by a computer program where the program is unable to release memory it has acquired."

What this means is that its not a leak until it can no longer be referenced.

Creating handles in wc3 is the source of memory usage. So I think it is fair to say that they cause the leaks trigger-wise.

Creating strings, integers, reals, and booleans are all sources of memory usage, but they don't cause leaks "trigger-wise". You clearly have a poor understanding of memory leaks, so you can believe whatever you want. I just want the reader of this thread to know the facts about memory leaks rather than your "opinion" on what they are.