On Friday, February 20, 1998 6:00 PM, Daniel Koepke
[SMTP:dkoepke@CALIFORNIA.COM] wrote:
> On Fri, 20 Feb 1998, George wrote:
>
<snip>
>
> Why stop there? Well, my answer, to be perfectly blunt is: because
> it's a waste of time to even get there. After completing this part of
> the message, I copied it to a text file and checked its size; then
> compressed it with gzip (-9) and checked its size again. The results
> are:
>
> Before compression: 267 bytes
> After compression : 203 bytes
> Savings : 64 bytes
>
> Now, admittedly, some room descriptions are longer than the four line
> one above; but others are smaller. So, I think it's a good average
> length for room descriptions. Now, let's say we have 6000 rooms on
> our MUD (I don't know what most people have; I suspect more,
> but...<shrug>), we get,
>
> Without compression: 1.6mb
> With compression : 1.2mb
> Estimated savings : 400k
>
Let me start off by saying I complete agree with you, in that compression of
mud data in memory is better handled by the paging mechanism in a good OS.
With that said, I think your results were skewed in favor of your argument
:-)
You could create a compression routine that would read in all the roomdescs
in a zone [as a stream] and thereby gain _much_ better compression ratios..
though you now need a header to keep track of the ofsets into the data
stream to put everything
back when the time comes. (This amounts to a routine to feed the compression
routine and write the table more than anything.. and something to reverse..
wouldn't be difficult to code.. just tedious typing it all in.)
However.. if people want to save some RAM, I have a few other suggestions:
1) Setup your mobs and objs so that data that doesn't change is referenced
via the prototype. (ascii pfiles are a must)
a) Split the data in your obj/mob structures to partition the changeable
/ non-changeable data into seperate structs inside the main obj/mob struct.
b) When you load a mob/obj, have the struct that points to non-changeable
data point right back at the prototype.
c) Create macros to all the non-changeable data (or rename the ones that
exist, etc). Insure that you use some identifier so that you'll know they
are RO entries only changeable via olc or whatever.
d) side-affect: If you change something in olc, the next load of that item
will use the newest non-changeable info.. I use this to good affect when
creating items, insure there is a path to change items while minimizing the
requirement of taking objs away from chars, or reloading new ones in the
background on them. They don't like it when I do that :-)
2) Create seperate structures inside char_data for player, mob and immort
data. Create only the appropriate ones after creating the char.
3) Create a method of changing exits on the fly in your scripting system,
spec procs, whatever. Minimizes room waste when people make their mazes or
huge desert areas.
--Mallory
+------------------------------------------------------------+
| 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