Of course there may be scripts using /filter that could use hash tables instead.
But - for example - as items of a hash table are inherently unsorted, everything related to "keep things in order" is a pain (especially regarding performance) or imposible to obtain via hash tables, besides other filter features or related actions like strip, ranges, fast "duplication" of a [part of a] dataset (window content), loadbuf/-save etc pp.
Yes, that's the problem with hashes, order and mass operations. I use /filter for about anything, to number, to sort, to extract all entries with certain value(s) on certain token position(s).
mIRC lacks a memorybased data structure that keeps order and /filter-alike commands for it. A hidden custom window is perfect for this, only that the window as-such can be seen as a rather unwanted side-effect, but acceptable.
But this OS heap register size problem is an unforeseen and rather big obstacle in the whole idea, especially for a big script with alot functions where they are used all over the place, as data buffers and holders, queues, joblists, etc.
I only uses hashes for item+value paired configuration data and where order isn't needed and where hdel -w can cleanup for ex all entries for a given network.
However, I did not chose permanent @windows on a per network base, my queues for example use one window for all networks, the network name is just a token-element of a line. It causes abit extra overhead but that's all.
So the main effect of this heap limit is that it defeats the whole purpose of my script: being on alot networks and channels.
There was a day I believed that I could select 20 networks in my dialog, press a 'Connect' button and expecting to find myself, authed or identified on every network and on 100 channels, to act as bot and chat. I wrote a complex queue system to avoid flooding and keep mIRC responsive.
Until I ran into this * Error creating window, at a mere 50 channels or so, and * Error creating dialog when trying to open its interface. It's not fun.
