Global Point Variable = Does it leak?

[Cespie]

In the "Things that leak" sticky the answer is sort of implied with:

Unit - Create 1 unit at Somewhere

However, it doesn't explicitly say that this will not cause a leak, but below it, it makes an example which would obviously leak, as it creates a location based on a function, and states that this one would leak.

So it doesn't actually state that referencing a defined point, will not cause a leak. Although it is implied.

So, in no uncertain terms:

Will referencing a point that's defined in a global variable cause a leak?

I'm not talking about setting the variable, which would obviously cause a leak, as a new location has to be generated. I want to use defined points to avoid memory leaks in a map where I am using a lot of static locations which are never changed, so the points would obviously take up memory, but they shouldn't leak memory every time the point is referenced. I just want to ensure, that this is indeed the case.

 

[loktar]

if "Somewhere" is a UDG, it doesn't leak. Reference leaks occur when an agent variable that is never used again is not set to null.

This leaks until Somewhere is set to null or reassigned:

• Actions
  • Set Somewhere = (Point(0.00, 0.00))
  • Unit - Create 1 Footman for Player 1 (Red) at Somewhere facing Default building facing degrees
  • Custom script: call RemoveLocation(udg_Somewhere)

If you're just using a global location variable that never changes and is never removed, there is no leak.
At least, that's how I understand it.

 

[Cespie]

if "Somewhere" is a UDG, it doesn't leak. Reference leaks occur when an agent variable that is never used again is not set to null.

This leaks until Somewhere is set to null or reassigned:

• Actions
  • Set Somewhere = (Point(0.00, 0.00))
  • Unit - Create 1 Footman for Player 1 (Red) at Somewhere facing Default building facing degrees
  • Custom script: call RemoveLocation(udg_Somewhere)

If you're just using a global location variable that never changes and is never removed, there is no leak.
At least, that's how I understand it.

Right, so in this case, "Somewhere" is actually 84 locations. However, said locations are only assigned a point once, and are never again changed or deleted. I reference these points for pathing, which meant that before, when these 84 points were the "center of a region", I was generating 12600 locations to path 12x15x10 units through 7 points each. With these 12600 locations, the memory leak was somewhat visible, yet not glaringly terrible. So if it comes down to me using 84 locations, then I am okay with that. All I want to ensure, is that calling these points doesn't create an instance (object) using the global variable as a class of sorts. It would make no sense for it to be programmed like that, but I just wanted to be sure that I wasn't missing a concept that I am not aware of in designing it this way, since every example I've seen assigns the location to a temp variable and then deletes the location afterwards. I use this approach for a lot of other scenarios, but in this case, it just isn't possible due to how much of a synchronization nightmare this thing is if I use any dynamic variables whatsoever.

 

[loktar]

If you're gonna be using the same locations a lot I think it's better to keep them in global variables than to assign temporary variables each time you need them, because then you'd be creating these locations again each time, which is probably more expensive than just keeping them stored. So I think you're all good.

 

[Cespie]

If you're gonna be using the same locations a lot I think it's better to keep them in global variables than to assign temporary variables each time you need them, because then you'd be creating these locations again each time, which is probably more expensive than just keeping them stored. So I think you're all good.

That's comforting to hear. In the time it took to get the OP mod-approved, I have implemented this, and my gut instinct tells me that it worked. It's kinda hard to see memory leaks in single player, I usually notice it when computer controlled units have delays in orders (Taking time to move when attacked, etc).

Is there a way to check for memory leaks in-game that's a little less based on rough intuition?

 

[Wrda]

Referencing != creating. Seems pretty obvious.
Reference leaks only occur on local variables, you don't need to set global variables to null.

 

[loktar]

That's comforting to hear. In the time it took to get the OP mod-approved, I have implemented this, and my gut instinct tells me that it worked. It's kinda hard to see memory leaks in single player, I usually notice it when computer controlled units have delays in orders (Taking time to move when attacked, etc).

Is there a way to check for memory leaks in-game that's a little less based on rough intuition?

Check out Things That Leak and for more detail Memory Leaks
Handling leaks is actually pretty straight forward once you know what to look out for.
Pretty much comes down to this: always use RemoveX() or DestroyX() for types that have them, and local agents should be nulled (thanks @Wrda for reminding me that only local variables have reference leaks).

 

[Cespie]

Referencing != creating. Seems pretty obvious.
Reference leaks only occur on local variables, you don't need to set global variables to null.

It DOES seem obvious, but what seems obvious is not always the case.
Either way, I am very happy to have this confirmed. Makes me sleep better lol.

 

[Cespie]

Check out Things That Leak and for more detail Memory Leaks
Handling leaks is actually pretty straight forward once you know what to look out for.
Pretty much comes down to this: always use RemoveX() or DestroyX() for types that have them, and local agents should be nulled (thanks @Wrda for reminding me that only local variables have reference leaks).

I've heard conflicting opinions on whether or not Strings leak.
Most say that they do not, while some say that they do.
Strings are said to be primitive in WC3, which is kinda new to me, as I am used to them being objects in Java.
Purplepoot wrote in a reply to "Things That Leak" that Strings technically leak. Can anyone elaborate on this? Is it worth considering at all?

 

[loktar]

I doubt it has much impact on performance, and either way there's nothing you can do about it besides avoiding using strings.

 

[Wrda]

there's nothing you can do about it besides avoiding using strings.

That would be so radical
Nah, strings afaik do leak, but only once, permanently. A string with "a" and another with "a" in another trigger, the latter won't leak, because the "a" is already in the string table, which you store from the former string. This is what I've heard. (feel free to prove me wrong)

 

[loktar]

That would be so radical

lol I guess one type of string you can avoid using is order strings, using their integer IDs instead