Hi, does anyone know what is maximum size of a hash table? Official mirc help says that N stands for the number of slots, but it doesn't mention any maximum number.

Another question is, is it possible to change the table's size without having to create a new one? (i'm asking this mainly for cases where the size of the table is unpredictable. If a table was created with N=100 and after a while the number of slots is 10,000 then it'd be a good idea to increase N to, lets say, 1000.)

http://xise.nl/mirc/wiki/doku.php?id=hashtables

Maximum N value is 10000 and it's impossible to change that value.

Theorically true, but then you can just save the current table and reload it into a new table, if that's impossible to do efficiency-wise for you, well use a dll.

Thanks for your response!

So, if Nmax is 10,000 is this is also the maximum number of real "buckets"?

More or less, yes

Well, yes, but as i read in the mirc page:,

So basically if N limit is 10,000 then the actual data that it can store should be far more. Tutorial says "unlimited", yes, sure, it can't be unlimited but there must be some kind of connection between declared and real limit

This is not an official mIRC website, and this page's wording is.. poor, the number N you pass in /hmake is a number of slot, it's not the number of item you can have nor a limit on the number of item you can have.
You have a good analogy of how hash table *works* here. Basically, slot are just rooms, each room contains a list, and when you add an item, it automatically finds a room, then the item is added at the end of the list in that room. These lists are not limited themselves, only RAM and Windows will put a limit on how many items you can have, so these limits will vary from machine to machine, and depending on the items themselves

The limit is not imposed by mIRC, so from the perspective of the program, it is unlimited. The only limit is your system environment. With memory paging to disk, that extends well into the terabytes, likely well beyond the scope of any kind of data that mIRC could conceivably process anyway.

So really, the only limit is your mind.

Though, as a theoretical exercise, it is worth noting that any table with N significantly larger than the bucket size will eventually start to see O(m) (linear) performance, so if you really are dealing with gigabytes+ worth of entries, the max bucket size may actually create performance bottlenecks-- though to be fair, those bottlenecks will be much smaller than the loops/commands used to write/read/process the data in your script. Of course, if you really do end up in this situation and want to minimize impact, it would be simple enough to create multiple hash tables to spread load horizontally (commonly known as data sharding). But seriously, you're unlikely to ever hit this perf issue-- this is a theoretical issue, not a practical problem.