Actually, mthreads.dll is a dll specifically written for mIRC to allow multiple scripts to run next to each other. I doubt I'll find anything about a mIRC specific dll in the MSDN library. That or I totally mistook your advice.
I know that it's meant for scripts, but it's likely just a thin wrapper over the
CreateThread API call. Again, I'm not positive, but I'd bet that would be the case. If it is, MSDN has a LOT of resources on threaded programming in windows-- what can go wrong, what the architecture is like, what your expectations should be, etc. It's a good starting point regardless of mthreads' API.
I'm already using multiple hash tables, some read-only and some dynamic. The read-only hash tables aren't saved of course. As for the dynamic hash tables, one is over 12mb and will keep growing fast, while the others are under half an mb together. I can probably think of an alternative to the single one large hash table, just haven't come around doing it yet.
It's the 12mb hash file that you should be splitting up. I'm sure there's a way to further isolate the data you use. Even if you just split them up randomly (choose table based on $r(1,2)) you could schedule your saves independently and reduce the wait-time. For instance, you could have 2 timers saving each table, each running 5 minutes apart (but at 10 minute intervals)-- then, instead of 3-4 seconds of delay every 10 minutes you would only have 1-2 seconds of delay every 5 minutes. You could continue this division as necessary until you have negligible delays (1/4 second every 2 minutes).
It's not really a maintainable solution if your data is growing fast, but it's yet another optimization you can consider if you've tried other options.
