Thanks argv0, you've been a great help!
I cannot answer this. I would guess that the dll is a very low level API over pthread or Windows' threading API, and you can probably find much more documentation on MSDN.
I don't know enough about mthreads.dll to comment. It looks like it just separates the script engine from the UI. mIRC will continue to look active but the script layer will be blocked. This may have unwanted consequences, though I'm not sure exactly what. I wouldn't recommend using it, in general.
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.
If it's taking 3-4seconds to save, you've probably outgrown hash tables, or at least outgrown using a single hash table. As I mentioned earlier in the thread, you probably shouldn't be loading all of your data directly into memory if this is the case. You should consider using sqlite or some data store with the ability to index your data and optimize lookups without requiring everything in memory. This would also guarantee persistence, too (no 10 minute timer needed for saving data).
Alternatively you can use multiple hash tables-- one for persistent read-only data storing the bulk of the data but only saved on exit, and one hash table for new and modified entries that were added in your current session only. That table would be much smaller and would be the one that was saved every 5-10 minutes. When you close mIRC (or force a flush to disk) you would move the data from the "current session" table to your persistence table and store that.
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.
I'll leave mthreads.dll and sqlite for possible future plans. Lots of work left to do in the near future. All my calls from and sends to hash tables are aliases, so reworking, while it would be a large project, wouldn't require me to dig through the entire code.
