Does hashtable leaks?

[polo2005]

I couldn't really find a decent clear hashtable tut for gui users, so i got to ask, does hashtable leaks if i overwrite a value that i have stored?

 

[Accname]

I couldn't really find a decent clear hashtable tut for gui users, so i got to ask, does hashtable leaks if i overwrite a value that i have stored?

As far as i know it does if you dont clear the childhashtable before overwriting it.

To be honest, i dont work with the editor anymore and i never really used hashtables but this is what i was told.

 

[polo2005]

well, i have stopped using world edit, but i got a request of a friend
and sincei never rly used hashtables in wc3 i though it was a good way to waste time

ontopic again:

can someone confirm if you need to clear childhashtables before overwriting them again?

 

[keychup]

If you clear data from a hashtable, how will you ever call for the variable in your other triggers? isn't that the point of hashtables anyway? So that triggers can refer to the same data?

And btw, you can try clearing all child from the key parent. i don't think tuts saw that they had to explain something as plain as what can be read.

 

[polo2005]

you missed my point, lets say i save my gold in hashtable as 0 0 in MyHashtableTest, and then 30min later, i store my new current gold as 0 0 in MyHashtableTest, would this cause a leak?

 

[GFreak45]

no, what causes leaks is handles being lost in the ram, and thats caused by a trigger running its course without removing any handles in the local variables, because they are still referenced, the issue with leaks in hashtables is say when you have a hashtable with data saved like this:

• Hashtable - Save Unit SomeUnit as (Key SomeOtherUnit) of 0 in last created hashtable

then SomeOtherUnit dies and his handle is recycled, but there was a reference off that unit to another unit, that way "SomeUnit's" isnt recycled until the game uses the same exact handle it used for SomeOtherUnit again, and even then you would have to clear the new units hashtable, it basically winds up making a leak that "can" be removed but is very unlikely

 

[keychup]

Which of these is the parent and which is the child?

 

[KaerfNomekop]

In GFreak's example, I think 0 is the parent and (Key SomeOtherUnit) is the child. So to clear it you would clear all child hashtables of 0.

Or at least that's what I think. My knowledge of hashtables is confined mostly to using them.

 

[keychup]

Then that means you can't simpley clear all children right? some may stop using it but others still are.

 

[Dirac]

Actually GFreak is both right and wrong, what mainly causes the leak is the creation of handles and leaving them loose around.
Basically the reason of why GUI groups leak, the editor creates it for enumeration, but when the variable is replaced and the previous group still exists, but no variable reffers to it so no one can ever destroy it now, piling it with the rest of non-destroyed groups, locations etc.
Doesn't have the same effect on units since unit handles are automatically recycled when the unit is removed or it's decay time ends.
"Hashtables" per se do leak
If you create 1 hashtable per spell you'll end up filling your ram of hashtables, they occupy a space in your RAM just by existing there, as well as anything does, the issue comes down when they pile up.
Clearing a child hashtable doesn't clear leaks, it might even cause them.

 

[keychup]

Would this be appropriate?

As you can see i am implementing a single hashtable for moving units and another for other abilities. I have incorporated up to 2 abilities into the zz_movement_hashtable and 5 abilities into zz_ability_hashtable. Would this help prevent leaks?

 

[KaerfNomekop]

Using one hashtable should be sufficient for most maps. Rather than using integers, you should use the (Key String) function. With integers you need a reference list to remember what refers to what; replacing them with things like (Key MovementAngle), (Key MovementTime), (Key MovementDistance) etc. lets you easily remember what they point to.

 

[keychup]

simply perfect

 

[GFreak45]

Actually GFreak is both right and wrong, what mainly causes the leak is the creation of handles and leaving them loose around.
~snip~
Doesn't have the same effect on units since unit handles are automatically recycled when the unit is removed or it's decay time ends.
"Hashtables" per se do leak.
~snip~

i did not realize that, i thought the handle remained as long as it was referenced somewhere, i guess thats a difference in GUI and Jass leaks, since GUI doesnt use locals, but i do think i got the main point accross... and ya, 1-2 hashtables is the most that should be used because they do take up extra space, Dota uses 2 currently and that is a very extensive game, the only reason to use more than 2 is for intensive systems, ie: Threat Systems, cast systems, etc, where many many units are recorded at once and you need both (Key Unit_1) of (Key Unit_2) and (Key Unit_2) of (Key Unit_1) in the same system and need it in another

and instead of using (Key String), create an integer variable called, say... Hash_Key_MovementAngle and just make sure it has a unique integer so u dont reference the same parent/child at once with 2 different systems, integers are more efficient than String handle calls because they actually call a function

 

[Dirac]

With vJass you only need 1 hashtable, doesn't matter how much use you give to it
And yes, sadly locals cause leaks, if you don't null them. The reason is that handle references do have a small impact on RAM storage, very small though, but locals are generated every time the function is called, and more and more references remain. Doesn't happen with globals because they are declared at initialization, you can't create a global during the game.

GUI -> Very hard to avoid leaks, LOTS of ram usage, LOTS of code size, LOTS of time wasted clicking OK buttons, LOTS of speed loss caused by heavy hashtable usage and timer spamming
vJass -> Avoiding leaks is easy, minimal ram usage, reduce code size considerably, saves you a lot of time by coding by your typing speed and using fully functional, speedyfreakish, pre-existed systems developed by other people online..... for free, also a vJass map runs at least 1500% times faster

It would be a fool that who denies to learn JASS IMO, no matter how "hard" it looks from your point of view, you can learn it in less than a few sessions

 

[GFreak45]

i just wish that JNGP was getting updated more frequently, there are a few changes that would be nice, ie: expanding textmacros before modules and then static ifs after those, however at the moment i believe it's static ifs -> modules -> textmacros
eventhough textmacros are the most customizeable
if you could do it in the reverse order you could make WAY more versatile systems
or if you could take variable arguments or array arguments like in C++ rather than just flat value arguements
I do aggree with you that everyone should use vJass but 12% of people who own computers own macs, and JNGP doesnt work on Macs (idk about JH) which presents problems for a lotta people (like smitty)

 

[Dirac]

I have a Mac and I installed Windows XP through Bootcamp.
Silly impediments people hold on to not to learn vJass
And don't misjudge, I coded in GUI for a long time (Just search for my ChainHook spell)

And no, currently the compiler does this
module -> textmacro -> static if
So you can declare static ifs inside modules or textmacros to check if things exist where the user runs/places them. (Just read my Missile library or Nes's Unit Indexer)
It would be cool to take arrays for an argument, but it cant be done. The compiler isn't a language itself

 

[GFreak45]

i know but its just a wish >.<
guess were stuck using Interfaces
and i was more concerned with the module -> textmacro as that held me back a while back ago with a system i was working on for my rpg

 

[Dirac]

There's always a way to avoid interfaces, no matter how ugly the API looks like.
are you sure that textmacros compile after modules? It's also a possibility that they compile at the same time in linear order (if there's a textmacro above a module then it should compile first)

 

[GFreak45]

that was Per Nest and Luorax (if my memory isnt failing hard, which is totally feasible)