hashtable memory usage

[W!†A_cRaft]

If i was to for example create a hashtable with parameters like this:

local integer i = 0
local integer j = 0
local unit u = <some unit>
loop
     exitwhen i == 100
     loop
          exitwhen j == 20
          SaveUnit (udg_hash, i,j,u)
          set j = j + 1
     endloop
     set i = i + 1
endloop

Now if i for example want to clear a certain part of the table lets say

local integer i = 10
loop
     exitwhen i == 15
     call FlushChildHashtabled(i)
     set i = i + 1
endloop

now if i take a look at my hashtable it will have fields like:
        1    2    3   4   5   6   7   8   9   10    11   12   13  14  15  16  17  .  .   .20
1      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
2      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
3      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
4      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
5      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
6      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
7      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
8      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
9      u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
10     .     .    .   .   .   .   .   .   .    .     .    .   .    .   .    .   .
11     .     .    .   .   .   .   .   .   .    .     .    .   .    .   .    .   .
12     .     .    .   .   .   .   .   .   .    .     .    .   .    .   .    .   . 
13     .     .    .   .   .   .   .   .   .    .     .    .   .    .   .    .   .
14     .     .    .   .   .   .   .   .   .    .     .    .   .    .   .    .   .
15     .     .    .   .   .   .   .   .   .    .     .    .   .    .   .    .   .
16     u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u 
17     u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u
.
.
100    u     u    u   u   u   u   u   u   u    u     u    u   u    u   u   u    u

These 5 empty fields that i gotten by flushing child hashtable are still there, they are just empty?

Now if i lets say add another "row" basically 101, will it overwrite a place in memory that was empty or will it just make a new row.

if it makes a new row, do these empty rows cause lag/delay and things like that?

 

[Sgqvur]

>if it makes a new row, do these empty rows cause lag/delay and things like that?

Of course not : ). This is Blizzard's implementation of a hash table specially designed for their awards winning game and by top level programmers.

I think I read somewhere that they had to pull some extra crew from d2/3 team to help fix the return bug exploits. But they had to replace the lost functionality for the popular maps (like TcX, and I think some map called dota? ... idr) so they added those new natives. It's a win win except for the thousands of old and good maps that got broken.


about:
>These 5 empty fields that i gotten by flushing child hashtable are still there, they are just empty?
and
>Now if i lets say add another "row" basically 101, will it overwrite a place in memory that was empty or will it just make a new row.

Well I don't really know much(null actually ; )) details about the internal implementation of a hash table but I guess it's made that it is pretty efficient.

 

[W!†A_cRaft]

well the only thing that has me worried is the "overtime lag/gameslowment" because RAM memory would get used up with parent keys.

I am using something like this:

a 2 unit relation, stored in a hashtable:
Unit A - Get unit Id 1
Unit B - Get unit Id 2
SaveData(hash, ID1, ID2, value)

and when unit A decays (i.e. loses his ID) i use a FlushChildHash(ID1) to clear all the data related to that unit...all the data except the parent key which is still in the hashtable....

so if for example every unit in my map decays i would have one BIG empty hash table filled with parent keys.... Would this still take up place in RAM memory?

I mean there would be a TON of relations in my map, but only like 20-40 relations at every single time, after which, they are dumped, that is why i need to know if it will cause RAM clogging.

 

[luorax]

I think hashtables're 2D variables (matrixes).

 

[W!†A_cRaft]

I think hashtables're 2D variables (matrixes).

yea we are aware of that...i even made a picture

 

[Jedi]

Just flush your hashtable and hope for the best, or test it yourself.

 

[Sgqvur]

>that is why i need to know if it will cause RAM clogging.

I like to think about a blizzard's hashtable like a black hole that can take any amount of punishment(inserting/saving) and (unlike a black hole) return it without any overhead.

If you really want to "save" the ram then I guess you could use the gamecache which saves it's data to the hard drive so it's more or less infinite and clogging-proof : )

 

[Accname]

its safe, no leaks when you clear the childtables.

hashtables can even be used with GUI without memory leaks.

 

[W!†A_cRaft]

its safe, no leaks when you clear the childtables.

hashtables can even be used with GUI without memory leaks.

but parent tables are still there, even though they got no childeren, parents still exist

 

[Jedi]

Umm, flush parents?
It doesn't matter they exist unless you save something and forgot to flush.

 

[W!†A_cRaft]

i cant flush parents that would dispose of them all, even the ones I'm still using.

 

[Sgqvur]

// Those clear individual entries
native  RemoveSavedInteger                    takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedReal                        takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedBoolean                    takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedString                    takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedHandle                    takes hashtable table, integer parentKey, integer childKey returns nothing

// Clears the whole hashtable
native  FlushParentHashtable                        takes hashtable table returns nothing
// Clears an individual parentKey
native  FlushChildHashtable                    takes hashtable table, integer parentKey returns nothing

 

[W!†A_cRaft]

// Those clear individual entries
native  RemoveSavedInteger                    takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedReal                        takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedBoolean                    takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedString                    takes hashtable table, integer parentKey, integer childKey returns nothing
native  RemoveSavedHandle

wouldn't these still leave parent keys in the hashtable?