What you just said made no sence.
if you go /hmake test 10000 it still has ZERO items, thats just a number to uses for the initial number of slots (i think that means differing returnable hash values).
As i understand it, its like issuing 10,000 numbers from 1 to 10,000 out, then you add an item called "BLAHHO" and you hash "blahho" into a number it might be 3,478, so go to box 3478, if its empty put BLAHO and its data in the box, repeat this for each item added. If u add lets say item "CATTAILS" and it hashes to 3,478 you go to that box, theres already something in it, so find the next free box after 10,000, lets say its 10,001, and put CATTAILS and its data in there, now go back to box 3,478 and on its lid write down 10,001, later you come to add item "FLEAS" and it also hashs to 3,478 so go to box 3,478 its full, so find a free box after 10,000 , and u find 10,092 is free so put it and its data in there, go back to box 3,478 and well damn somethings already written on the lid, so get that number 10,001 go to that box, that lids clear so write 10,092 on it.
So now if u go to look up "BLAHO" or "CATTAILS" or "FLEAS" you get 3,478, you now only have to check box 3,478 if its not the one u want follow the number on the lid to 10,001 and if thats not it follow that one to 10,092, simply 3 accesses, rather than looking through 10,000+
*of course i simplified it alot, like didnt mention how it would check if the items existed or not already, but im sure u could see that logic.
Assuming you had 2,000,000 items on average there would be a linked list of boxes to go through 200 long to find any one item, 200 accesses, if u didnt speciifcy a size the defualt 100 is used and the linked list would be 20,000 long each, in either case it appears accessing these items is rocketingly quick.
However the time to load the table increased considerably (10 fold) between having a HMAKE 10000 and only a HMAKE 100 (100 was x10 the load time)
