Strings & Memory Usage

[Shawn Halpenny]

On Apr 14,  8:07pm, Greg Munt wrote:
> Subject: Strings & Memory Usage
> Is there a common way to save the memory used up by storing strings? I'm
> sure something was said on this subject in the RGMA 'MUD Memory' thread
> (by George Reese, IIRC)

I'm curious about this too.  I haven't thought all that much about it and,
given that, could certainly benefit from others' trials and tribulations to
point me in a sensible direction.  Right now I'm thinking hashing, but
nothing more detailed than that.

>
> I will probably be using some sort of bytecode compilation on my mud now.
> Would this method of memory saving simply involve checking a list of
> those strings currently in memory, and either adding a new string, or
> adding a pointer to an old string? (that would probably slow down the
> process unless the storage structure was right, tho)
>
> Thanks,
> Greg.
>
> PS On the subject of project management, I was planning on some sort of
> autocratic method, quite simply because I have experienced first-hand the
> political nightmare of a democracy (see my intro). I'll probably have
> some communication medium through which people can talk about design
> ideas, then I would decide what I wanted, and share the work out to
> numerous people. One of the goals of Frontiers is to have a code base
> which *anyone* can contribute to - thats one of the reasons i'll be using
> the copyleft. Probably a core base of serious programmers, and
> 'contractors' who want to do the odd feature here and there. I do think
> it important that the programmers dont make unilateral design changes
> while coding tho - they should report design flaws, where a solution
> should either be given by me (if a simple fix), or discussed by everyone.

My approach was to break the design into two parts (a lot like an LP, I
suppose):  kernel and lib.  The kernel handles all the nitty-gritty, the
stuff that no one creating their own mud should need to know the
intricacies of, while they can build their own lib to suit.  IMO, this
prevents the tragic proliferation of stock-muds too, once a number of
from-scratch servers are released.  That is to say, just release your
kernel.  Don't release a lib at all, document the hell out of your
kernel and perhaps supply a whole bunch of examples (sure, pull them from
your lib), but don't give anyone else a complete world to start with,
otherwise you'll just end up with a situation like we have now (server
quality notwithstanding).

I'm at the point where I'm considering being a rat bastard and not
releasing anything (not selling it, but making it the only one in
existance), but that could just be because I'm discouraged by all the crap
that's out there and don't want the same to happen to mine.  I'll probably
smarten up and listen to what I wrote in the preceding paragraph sometime :P

Heh...somewhat rant-ish :>

> The documentation of every development stage is of paramount importance -
> it sickens me how poorly documented muds and code bases are. In fact, it

Too true.  It's _way_ to easy to hack something up and then have to patch
it and hack it all over the place to make it do what you want, whereas if
you'd started with an actual design, some goals in mind when you started
(and wrote them down and thought about them and bounced them off others
yada yada yada), you end up with a much easier-to-work-with finished
product.  IMO, the only way to go.

--
Shawn Halpenny