Forums mIRC Help Are global variables stored in memory?

The topic basically says it: are variables which are set with the /set command loaded into and read from RAM memory (like /var) or - since they are stored in vars.ini - constantly read from the HDD?

In other words, how 'bad' is it to use a global variable in a script that is constantly triggered?

The help file wasn't too clear about this. The application of /var -g isn't too clear either, regarding the fact that those variables only exist for the duration of the script routine.

//var -g is the same as /set, it just let you set more than one global variable in one line.
Yes, global variable are stored in the HDD, so yes, it's slower than using hash table for exemple.
It's just a matter of speed, if you're making something related to irc, then speed isn't very necessary, and global variable can be used, but if you're making a picture window game, you'll see the difference between using hash table and global variable.In your case, if the script is triggered constantly, use hash table, it will be faster, but you will probably not see the difference.

All variables (global and local) are cached in memory. Contrary to the above comment they are not slower than hash tables.

Really ? i'm surprised, i've always heard that variable was slower in general and the test i've made in the past show that it was true but i'll re-make some test.
How do you know that they are cached in memory ?

Edit : of course i'm talking about global variable.

It seems variable read/write access times are affected heavily by the number of variables already set. My original benchmarks were based on only a couple of global variables existing at once. Setting 5000 unrelated global vars slows the original benchmark to 1/20th of its original speed which is a looong way behind the hash table benchmarks.

As always it looks like there's no straight answer about performance and it really depends on the situation. Generally though read/write performance isn't the deciding factor in a storage method anyway, usually the choice is made by the features required (such as hash tables' powerful searching of large datasets or custom windows' sorting capabilities).

Yes, i have the same result.

I don't know why you're saying that variable are not slower than hash table.It's possible that speed will depend on how you use %variable or how you use hash table but I really hope you can answer the question "how do you know variable are cached in memory ?" because this is interesting.

I said that primarily on the basis of the benchmarks I'd done using only a small number of variables (in which case variables are approx. 25% faster than hash tables). Obviously if you have a large number of variables then that won't be true.


Simply because mIRC caches all of its script/settings files (hence the existence of the saveini command). I would hope it has an additional variable-specific in-memory structure beyond a simple cache of the variables file, however the performance I've seen tonight suggests otherwise.

In general practice you wouldn't page out on each variable update, nor unload the cache. What you're seeing in file writes I'd suspect is mIRC simply dumping the current cache of the variables to ensure the integrity of variables as a redundancy. I don't know this for a fact, but it would make the most sense.

Imagine using /hsave after every /hadd for a Seen Database that tracks on TEXT in a 2000+ high traffic channel.. That'd be a bad practice, however periodically saving on an interval would be sufficient or (what I believe mIRC is doing) after a queue of updates has completed.

Now I've always thought mIRC only flushed on exit, but perhaps K changed it awhile back and I've just been out of the loop too long, but I remember when you used to have to rely on /flushini.

Ok thank you

_Memo, with what you said, it mean that some data could be theorically saved, but if mirc crash, thing that have been saved (by the user) will be just lost ?

Yes, in my example the hash table would be lost if mIRC crashed.

Like how some scripters practice only saving ON EXIT. The idea solution to prevent data-loss would be to periodically force a save (with a timer), or use a queue and once the queue was empty, then save. Which I would imagine mIRC does the latter for it's internal cache to prevent data-loss in an uncontrollable situation such as a crash, the process being killed, or any situation which would prevent it from performing normal exit operations.