Hrmm... in relation to my last post about paused threads to call a function after a period of time, I finally used the simple solution of a MUSH timer firing every 0.1 seconds. What is being fired is this:
def cureHerb():
global herbbalance
if len(herbqueue) != 0:
if herbbalance and not affCheck("anorexia"):
eatHerb(herbqueue[0].cure)
herbbalance = False
The question is, why is this causing a 4 kB memory leakage per second? When using all my timers (this is just one of five or six), I have about 50 kB leakage per second, and at times it goes crazy and goes up to about 2 MB/sec. I can cope with this for a while, but it's really annoying to have it nagging at the back of my head.
One key to solving might be that if I save the script and reload it in MUSH, the memory usage goes down a shitload. However, even though it goes down, it goes down to a value far above what is normal. Around 300-450 MB. I can live with it, but I shouldn't have to. Any ideas as to what the problem might be?
I don't know how Python works and where it declares variables and so forth. But one thing is that you declare herbbalance to be global; I'm assuming that is telling Python that that is a global variable. But you're not doing anything with herbqueue; does that also have to be global?
Otherwise, it might be assuming that herbqueue is local, and allocating memory for it. What you're seeing probably isn't memory leaks as much as just waiting for the garbage collector to kick in.
It is out of my control whether or not script engines consume lots of memory. Possibly there is a garbage collector you can manually trigger every 10 seconds or so. I know Lua has such a thing.
My experience with memory usage is that it can be a bit puzzling, and once a program (such as MUSHclient, or DLLs inside it) requests memory from the operating system, I am not sure it ever gives it back, so that the memory usage reported by Windows may gradually increase, or at least never return to its initial state.
The excess memory is probably written to disk in the page file, so even though it may be reporting large amounts of memory usage, it hopefully won't slow down execution much.
As a comparison, my copy of MUSHclient (which is using Lua scripting for its main world), and also has 3 plugins loaded, is using 8944 Kb of memory. It reports being up for 1 day, 19 hours. So, that is about 9 Mb after running almost 2 days.
Perhaps try Lua scripting, see if that makes a difference?
This could be a problem with a combination of timers and Python. Try calling the same function in a loop a few thousand times and see if it still leaks (it really shouldn't leak from the looks of it).
I made a function that called all the functions in question ten thousand times each, and did that about a hundred times in a row. Not a leak in sight. It seems I have stumbled upon a compatibility bug of some kind between MUSH and Python, as you say. Nick, any ideas?
More likely than not what you found is why a great many advanced users hate windows - horrible resource allocation. More often than not, once windows allocate resources they're not released until the system is restarted or some 3rd party trash collector goes thru and frees all the memory that's not actually being used anymore.
Odds are the problem isn't MC, Lua or the interaction between them - it's microsoft's sloppy resource management routines.
Quote:
It seems I have stumbled upon a compatibility bug of some kind between MUSH and Python ...
There is no difference internally between Python and (say) Vbscript, except for the word "python" at some point internally. Thus, any compatability should also affect all scripting languages, except Lua which is handled differently.
It is quite possible that whoever implemented the Python scripting interface inadvertently allocated some memory that they never free, every time a script is called.
Note to self: Restart Mushclient every once in a while.