Ok, so in the process of redoing even more stuff on my game. I began to question ROMs memory management setup.
Is is really worth it to keep the resource pool system they have going on for structures like CHAR_DATA and such instead of just creating and destroying them on command?
I understand it is "faster" to do it that way, but how much quicker are we talking, and is it worth the trade off now since computers are much quicker then when ROM was designed anyways?
It seems to me that if im creating and destroying everything on demand, i dont have to worry about if the structure was cleared out and fully reset before i attempt to use it again.
Input would be great. If im retarded just tell me, i can handle that. It just seem to me that keeping track of the resource pool is wasted effort, and since we never free anything if i experience high peak times only a short portion of the day i have all this extra memory gobbled up until i restart the server….
You can relatively easily measure the speed difference by allocating 1,000,000 objects using the pool method and then using the create/destroy method. What I can guarantee that you find is that the difference will not matter for the vast majority of MUDs.
Memory pools make sense when you're allocating and destroying a large amount of typically small objects in short periods of time, and all the more so in languages with garbage collection. Invoking GC takes time beyond simply destroying an object. As usual the answer is that it depends on what exactly you are doing, but again, in a MUD it is really very unlikely that anything you're doing would be noticeably affected by using a pool rather than direct allocation/destruction.
Rom memory management does not even work out of the box as soon as you have area effects anyway so well, you either better use a different code base if you are redoing, or really scrap EVERYTHING that is memory related of a rom codebase. And watch the discussion I had with Haley after I realised the problem :p Basically, only 'viable' thing is to free memory yourself, and implement a way to only purge memory when needed (basically, out of any loops).