Forums Feature Suggestions Auto-hash file management.

Let's say you have a hash file that grows and becomes smaller often. Just setting one slot value for it does not seem very efficient. Perhaps some setting could be added to make a hash table self-adjusting as needed.

Right now I have a script managing the hash table by checking to see if it's within my accepted range (items/slots) every so often, and if it isn't, then it frees the table, and reloads it with the appropriate number of slots/items. (meanwhile any other value that was supposed to have been taken out of the hash file or added is added to a lil queue list, the script then checks to see if the hash table has been reloaded yet at short intervals and keeps checking till it is, then performs those duties when able to).

Now, I do have a question. How important is it exactly? If I have a hash table with 50,000 items, and only 50 slots, what delay will I be looking at here? And vice versa, if I only have 50 items in a hash table with 5,000 slots, how much memory would that take up exactly? This would be useful info for the help file.

After doing a small amount of testing, making a hash table the sie of 100 or smaller adds no memory usage to mirc. At 1000, 4K are added to mirc, and at 10000 46K are added to mirc. As far as memory usage goes, mirc only uses it as its added to the hash table. Your way of recreating the hash table based on an addition and subtraction from it (from what i can see) is way more memory intensive. The fact that mirc has to free up the memory, then redeclair and reassign it every time a change is made to the table must eat resources.

Again, i didn't get too much into details, but leaving a table at, say, 1000 for a a 10000 item hash table is more than reasonable. memory will only be consumed (other than that first ~4K) as it is needed.

Except that the number of "slots" has no influence on memory usage, but processor usage instead.

In my experience, there's really no benifit in using values other than 100 for lists 1-10,000 items (that peaks at 100 items per index), and 1000 for lists that'll range 1-1,000,000 items (that peaks at 1000 items per index).

There is really little to be gained by rehashing your hashtable with a smaller number of indexes (slots). The balance of efficiency is difficult to calculate and often unnoticable, so it really doesn't hurt to have a few items in a large index hashtable for a while, unless you're really grinding away at it using all your computer's CPU.

- Raccoon