Because of the length of the message, I'll give the summary first, if you
still wanna read, then go for it.
summary:
Ouch. If you're under a memory limitation, make your code better.
There are many places in which your mud can be streamlined if you want to
put in the code to do it. If you dont' know how to write a memory
manager, your solution is not viable.
> Well there is a mud that has a limit of memory it can use, and the limit
> is pretty steep. Anyway, it has no limit in disk space, just RAM, so a
> swap file seems the perfect solution to limited ram and infinite disk
> space.
Most muds are limited in this way. Usually by the machine that
they're running, granted, but still. The best way to get the usage of
your ram is to code more efficiently. The amount of memory you'd use
trying to write a memory manager of any type, not to mention one directed
soley at file-based storage is probably going to exceed your memory limit
anyway. Thats what the OS kernel is for. Most Unixs perform rather well
here, at least, better than most of us here could create, although,
using the swap memory still counts as using memory.
> Also, no player is in all the zones at the same time, so writing
> that part of the zone index into the disk wouldn't be a bad idea, and when
> a player enters the zone, loading it from the disk. As far as mob
> wandering, possibly do it in shifts and go through the zones, for although
> swapping is slow, it is not that slow. Maybe make a swap array with a
> bool swapped flag to show which zones are swapped. And also an internal
> timing system to locate prime canidates for a swap.
This has been suggested and implemented in some cases - the zone
isn't loaded when there are no players in it, and if a zone needs to be
updated/reset, it will be when a player enters it, and it will be advanced
through as many ticks as needed. Note, the rooms which comprise the zone
are still there, just as the mobs are, the turn-by-turn run-through of the
zone commands isn't done. You could add a twist to that, and completely
unload the rooms as well, though, you'd probably want to find a way to
make the mobs and objects deal with the fact that they're not in a room
anymore. I wouldn't recommend unloading mobs and objs, since they exist
outside, and are accessed by other functions apart from the zone.
> Also perhaps a way to
> get it almost compatible between the OS's with the exception of a bit of
> ASM code.
If you're just writing to a file, you can use standard c
functions. If, for some reason, you want to set it up to look like an
actual swap file, you'll have to write a full-blown memory manager to run
your mud on, which will monitor its own memory usage, and then make calls
via some sort of memory pager to the file, and back again. If you've
never done it before, truthfully, you'll never be able to come up with
something that works well enough, and is itself efficient enough to make
either a) a difference in memory usage, or b) run the mud fast enough.
Let the OS handle it.
>
> although some programs actually write memory pages there. Also I wonder
> if there is a way to do it without defining my own memory page handler,
> maybe just swapping space already malloced.
>
Another thing you may or may not have noticed...all your memory
access is not direct. malloc, and free, and the like, these don't actually
affect the memory in the way you might expect. They make requests, which
the os grants in its own way, and time. Memory free'ed for instance, may
not be immediately released. Etc.
What this comes to is that you cannot _directly_ affect your
memory usage in the way that you'd like, unless you have your very own
manager, which consists mainly on files apparently.
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST