[General] clearing leaks on hashtables in GUI

[NBalfa]

how do you clear leaks on hashtables in GUI (need the code in custom scripts to clear parent, child and specific hashtables)?
if i save points in hashtables how should i clear the leaks on em ? (should i save just the x,y values of the point instead?
should i clear hashtables before overwriting em?

 

[Nichilus]

If you save location into hashtable, then to remove the memory leak you load the location from the hashtable into variable and use custom script to remove the location.

Saving X and Y coordinates of a point won't help you, it will actually be even worse.

You should clear that part of hashtable that you no longer use after you're done using it (IIRC so handle IDs of non-existing stuff is not in hashtable as that afaik would prevent the reuse of that ID for newly created stuff and could eventually slow down the hashtable as it would have to search through too many IDs to find the correct one).

 

[NBalfa]

what is the code in the custom scripts i should use to clear em (individual hashtable pairs as well as child hashtables)?

also when you say about the removal of the memory leak of a location hashtable, should i do it when i am done with the hashtable or even when i am going to overwrite it ?

 

[Dr Super Good]

what is the code in the custom scripts i should use to clear em (individual hashtable pairs as well as child hashtables)?

I already told you the native declarations...

// This will remove all key value pairs from the hashtable. It will return to as good as new condition.
native FlushParentHashtable takes hashtable table returns nothing
// This will remove all key value pairs under a certain parent key. Useful if you use the parent key as some kind of super identifier with children as indices (like parent as a unit and children for indices of data)
native FlushChildHashtable takes hashtable table,integer parentKey returns nothing
// These will remove a specific key value pair from the hashtable. Use the appropriate one for the type of value that was stored as otherwise these can be unstable.
native RemoveSavedBoolean takes hashtable table,integer parentKey,integer childKey returns nothing
native RemoveSavedHandle takes hashtable table,integer parentKey,integer childKey returns nothing
native RemoveSavedInteger takes hashtable table,integer parentKey,integer childKey returns nothing
native RemoveSavedReal takes hashtable table,integer parentKey,integer childKey returns nothing
native RemoveSavedString takes hashtable table,integer parentKey,integer childKey returns nothing

They work just like any other native declaration.

For example...

// Assumes a variable declared called "somehashtable" of type hashtable
call RemoveSavedString(somehashtable,0,0)
// Will remove a string from parent 0 at child 0.

 

[Nichilus]

also when you say about the removal of the memory leak of a location hashtable, should i do it when i am done with the hashtable or even when i am going to overwrite it ?

Seems to me that you should read some tutorial about memory leaks as it will clarify and help you in future when met with similar dilemma.

Hashtable is just a medium (like variable) through which you can access objects (which you "saved" into hashtable).
The object (in this case the object is location) is not destroyed when you clear hashtable. Clearing hashtable means that everything is set to NULL.
Just an example: Save unit's handle into hashtable. Then clear the hashtable - the unit will still live and remain in game. If clearing hashtable destroyed objects as well, the unit would die when hashtable is cleared. That, however, is not the case.
This logic applies to all objects (units, players, unit groups, special effects, etc. etc.).

So if you null hashtable without removing objects you don't need, then you won't have a way to refer to that object through the hashtable. In case of locations or for example unit groups that are not saved in any hashtable nor variable, you have no way to refer to them via any possible action, yet those objects will remain ingame, taking up your memory space, thus resulting in memory leak.

 

[Dr Super Good]

I think the topic creators problem is he is not clearing the hashtable mappings and instead sets them to default values. Although default values do act as good as it being cleared logically, for a performance point of view I am not sure if it destroys the mapping. Hashtable performance depends on the number of mappings it contains.

 

[NBalfa]

what are the differences between the clears the triggers have and the corresponding ones you have written above?
for instance if i clear all child hashtables of a child through triggers and if i do that through jass, what will be there that will differ?
again should i clear a hashtable pair before i save a value over it ? (so for instance i save a hashtable pair into a variable, then do stuff, change the value of the variable, then should i clear the corresponding hashtable pair before saving it again on it or should i not?)
also what is the code to clear a location in a hashtable

 

[Dr Super Good]

for instance if i clear all child hashtables of a child through triggers and if i do that through jass, what will be there that will differ?

You cannot clear all child hashes of a child as that is illogical (a child is a child so cannot have children). I assume you mean "clear all child hashes of a parent" in which case functionally there is no difference as they both end up calling the same native.

again should i clear a hashtable pair before i save a value over it ? (so for instance i save a hashtable pair into a variable, then do stuff, change the value of the variable, then should i clear the corresponding hashtable pair before saving it again on it or should i not?)

No you should only clear a child if the chances are it could never be used again from that point. If you are regularly manipulating the child and will continue to do so there is no need to clear it. Hashtables are one of the better written parts of WC3 as people like Bashiok actually spent a lot of time and effort making sure it was done properly. The fact they have GUI issues goes to show how badly written GUI trigger system is.

also what is the code to clear a location in a hashtable

Locations extend type handle so the handle clear native will work. Be aware that this will only removing the mapping from the hashtable allowing the handle index to be recycled, the actual location object is unaffected and still prone to leak unless removed else where.

 

[Nichilus]

You cannot clear all child hashes of a child as that is illogical (a child is a child so cannot have children). I assume you mean "clear all child hashes of a parent" in which case functionally there is no difference as they both end up calling the same native.

Actually NBalfa may be right on this one - in a sense. The GUI action is called "Clear Child hashtable" and the action is written as: "Clear all child hashtables of child *value* in *hashtable*" - there is clearly an error in there. However the tip at the bottom of the window says it correctly: "Clear all children of a specified parent in a hashtable." tho many people don't read those tips -.-

 

[NBalfa]

so how do i clear the leak of the location? should i just move it to a variable and then clear the location from it?

also if i am correct the parent is the first value and the child is the second in GUI right? (i am asking as the way it is written is quite disturbing: Save Value as Value of Value in Hashtable )

 

[Nichilus]

so how do i clear the leak of the location? should i just move it to a variable and then clear the location from it?

I've already answered that in post #2.

also if i am correct the parent is the first value and the child is the second in GUI right? (i am asking as the way it is written is quite disturbing: Save Value as Value of Value in Hashtable )

Look here: http://www.hiveworkshop.com/forums/2520340-post3.html
Someone else asked similar question so I posted what I knew about hashtables and even draw pictures regarding how they work.
There may be some small mistakes here and there, but it should contain enough info to help you.