Confirmation regarding leaks.

[GoGo-Boy]

Hi,
am out of the sudden no more sure about this.

Do local handle variables leak when they're not initialized and not set to null in the end?
Because I often have a local unit in my high frequency callback function for e.g. detecting units around a missile and do s.th. like this.

private function Callback takes nothing returns boolean
    local unit check
    call GroupEnumUnitsInRange(GROUP,x,y,AOE,Filter(function Filterblabla))
    loop
        set check=FirstOfGroup(GROUP)
        exitwhen check==null
        call GroupRemoveUnit(GROUP,check)
    endloop
endfunction

As I don't assign a unit to the variable when there's no unit around the missile, it does not leak or?

 

[GetTriggerUnit-]

I doubt it does leak but you should initialize null anyways.

 

[GoGo-Boy]

Hmkay, thanks.

 

[Nestharus]

Code in first post is fine =)

you don't have to initialize the variable and the code sets the variable to null after the handle is removed, so 0 memory leaks.

 

[GoGo-Boy]

But do I have any speed game in not initializing a local variable to null? (of course very little one).

 

[Kenny]

Speed isn't an issue when talking about initialising local variables. If you care that much, you are verging on insanity.

Just initialise variables as either [ljass]null[/ljass] for handles, [ljass]0.00[/ljass] for reals or [ljass]0[/ljass] for integers and you will be fine. It will also stop problems that can occur when you try to do something with uninitialised variables.

 

[GoGo-Boy]

Man, I'm just asking if it is a different and goddamn i don't give a f*** how much. I'm just interested whether or not.

And not setting em to null can help to debug stuff. Like the function completely stops -> I know I messed up giving the variable the correct value later on.

 

[weaaddar]

You should avoid FirstOfGroup loops, they perform worse than ForGroup/GroupEnum*.


The example is pretty ridiculous. GroupEnum* clear the unit group first.

 

[GoGo-Boy]

Hmm? I mean if there's actually no unit grouped. And doing ForGroup() stuff requires to do attaching again, which makes the code a bit worse and does take away performance as well.
I mean I could also use globals then but... meh, i heard coding like that is a bit low-brow oO.

 

[Troll-Brain]

But if you code inside the boolexpr, you could always return false, and then the group is always empty.
So that should be more efficient.
It's a matter of taste imho, i can't believe some one can have a performance issue, just because he use a FirstOfGroup loop instead of code directly inside the GroupEnum boolexpr ...

 

[Nestharus]

I always code my group loops the way Troll described: I put all of the code into the boolexpr for the GroupEnum.

In this way the group is always empty so no need for GroupClear or any of the other native calls = ).

Now, there is still a better way and that is by doing it via an array or linked list, but that's only useful if you do it one time over or if you are dealing with a small amount of units because you'll hit the operation limit (around 22k).


Also, initializing a variable commits it to memory. Once a variable is initialized it can't be un-initialized. The thread crashes because the variable doesn't really have anything yet, so it takes up 0 memory and what not. Initializing it at the start should only be done if you are planning to operator on it straight out rather than assigning it a value.


Unlike C++ and C and etc, variables are only removed from memory once they leave scope ; ). Arrays are auto initialized, so they immediately take up the memory =p.


Now, to go into more depth on memory leaks.

Just doing RemoveUnit would actually remove the handle leak. The other memory leak has to do with handle ids for the handle table. The ids aren't recycled until no local variables point to a given handle, even if the handle associated with that id has been removed. This is the reason why you have to null regular handles. The handle variables are actually pointers to them = ).

So when you null a handle, it frees up the index at the end of the cycle. These memory leaks are really small, but freeing up 10,000+ handle ids from an entire game can cause a long black screen. They can also lag up your game because you're increasing the handle table size. The reason for the lag is the extra time it takes to look up each given handle = ). This is the reason why cleaning memory leaks is very important ; P.


A lot of people also null strings, but that's kind of pointless =). Yea, you do free up the tiny amount of memory for the pointer, but strings added into the string table can never be cleaned up once added. I actually wrote this all out in a guide for JASS, vJASS, and cJASS = ). I talk about all of this very in-depth.


Really, there is a lot to JASS. While some things seem simple, knowing what goes on in the background can really be beneficial. For example, there is a perfectly good reason why array max size is only 8191 and there is a reason for the limitations on ints and reals.

Oh well, I assume that's precisely what you were curious about ; ).

 

[Joker(Div)]

When in doubt, just simply null. You're creating a war3 map, not some program with some maximum optimization required. How many games have you played where it lags not due to a large unit of units/effects being created at the same time? Just think about the old school days when 90% of maps where created with GUI littered with leaks. Pretty sure you were able to play those maps fine. Lastly, many people have upwards of 3gigs of ram nowadays. A few leaks here and there are not worth worrying over.

 

[Nestharus]

And rather than say don't worry about this or that, why not just answer his question and let him worry about what he will. If he doesn't deem it worth worrying about, then he doesn't. He might be just curious you know?

Man, I'm just asking if it is a different and goddamn i don't give a f*** how much. I'm just interested whether or not.

So rather than say, you shouldn't care about that sort of stuff, just answer his question. It's more productive ^_^.

If you don't know the answer, then don't post because someone is sure to post at one point who does know the answer.

I know a long time ago I used to be curious about certain things and when I'd ask a question people would always say, don't worry about that stuff. The fact was I just wanted to know how it worked -.-. It irritated me to hell because nobody knew the answer and the people who did would never tell me.

So rather than keep saying, doesn't matter, and etc, flooding the thread with all of this useless stuff that doesn't even have to do with the question being asked, just answer the question if it hasn't already been answered so we can all get on with our lives ^_^.

That's all I have to say about it ;p

 

[Joker(Div)]

Better to tell him now than later when he realizes he's wasted so much time worrying about leaks, he never really finished a map? (guilty)

It would be even more productive if the JASS thread was less of "Does this leak" and more of "What do you guys think of this" and such.

Your large post doesn't answer his question either. It's probably less relevant than mine.

 

[Nestharus]

Actually my large post where I answer his question does answer his question : )

Also, initializing a variable commits it to memory. Once a variable is initialized it can't be un-initialized. The thread crashes because the variable doesn't really have anything yet, so it takes up 0 memory and what not. Initializing it at the start should only be done if you are planning to operator on it straight out rather than assigning it a value.

Unlike C++ and C and etc, variables are only removed from memory once they leave scope ; ). Arrays are auto initialized, so they immediately take up the memory =p.

Initializing it should be slightly slower than regularly setting it, but it is an extra micro operation over all if you don't need it (initialize the first time you actually use it vrs the time the function starts). It's so small that it really doesn't matter, but like I said before, you should answer a question rather than say bleh. Let them come up with the bleh on their own ^_^.

So the reason I said don't initialize unless you actually require that initialization is because of that extra micro operation if you really care about it. As Joker(Div) pointed out, it really doesn't matter because it is after all a micro operation. As I said though, it's better to answer the question and let the questioner come up with their own conclusions rather than being told the conclusions without knowing why people came to those conclusions. Understanding the conclusions is better than being spoon fed them : p.

 

[GoGo-Boy]

Yeah actually Nestharus is pretty much hit the nail.
I am kinda curious about how everything works as I prefer coding and such when I actually know the background. I'm not going through my scripts now and remove every unnecessary initialization of local variables lol :>
And I pointed it out in my reply:

But do I have any speed gain* (misspelled it here ) in not initializing a local variable to null? (of course very little one).

I just wanted to know whether there is a difference or not.

And then a lot guys come and tell me something like "if you really care about this you must be an idiot lolz!!"
That's cool and interesting but doesn't even answer my question...

Well and of course thanks a lot for your detailed post Nestharus, it sure made some things clear. Maybe I gotta read through your Tutorial again. I just read a bit of it when it wasn't finished.

 

[Troll-Brain]

I'm happy to say, that for one time i'm totally with Nestharus here :thup: