From: d8andjo@dtek.chalmers.se (Johan Andersson)
Newsgroups: rec.games.mud
Subject: Re: Object Representation in MUDs
Date: 24 Jul 92 18:09:31 GMT
	<1992Jul24.054826.1@eagle.wesleyan.edu>
Organization: Chalmers University of Technology, Sweden
In-reply-to: amolitor@eagle.wesleyan.edu's message of 24 Jul 92 09:48:26 GMT

In article <1992Jul24.054826.1@eagle.wesleyan.edu> amolitor@eagle.wesleyan.edu writes:

>  Eeek. I don't see how this implies that it should hog memory.
>
>	   So, why DOES LP use so much memory?
>
>
Essentially because most data are kept in memory. Typical statistics:

 Sentences:                         12227   244540
 Objects:                            4623  2059588
 Arrays:                            62589  2324140
 Prog blocks:                         836  3474256 (211 swapped, 657 Kbytes)
 Memory reserved:                           800000
                                         --------
 Total:                                    8657984

			   (Stats from Genesis after 9 hours uptime)

Also, LPmud leaks memory. The driver needs a thorough overhaul. At the above
stats the actual memory consumption is 17Mbyte. There are some other
structures taking up memory but a fearsome amount of memory leaks away.


>  UberMUD
>  does not do classes, but it does pretty much all the rest (implementation
>  details differ, so it's a rather different server, principles are similar).
>
I have only looked slightly at MUSH code and I don't know how much more
creative freedom Uber gives. But to compare MUSH to a full programming 
language such as LPC is like stating that as long as it is Turing complete it
is as usefull to a programmer as any other language. 

LPC code in semicompiled form takes up approx 3Kbyte for a normal sized
program, give 800 to 1000 programs and you end up eating memory. 

>  UberMUD is also not a memory hog, using a rather snazzy caching arrangement,
>  that also gives decent performance.
>
Maybe LPmud could be redesigned to put more things on disk. You are welcome
to the task :-)

>mjr wrote:

> My advice to anyone contemplating a disk
> based MUD is to consider that determining that an attribute or object
> does not exist is every bit as important as determining it does.
>
We had a similar problem in LPmud with determining if a function existed in a
program or not, ending up in long searches for nonexistant functions. 
Linus Tolke of Lysator (and SvenskMud) came up with a neat solution as
all strings are shared and stored in a hashtable and functionnames are strings,
so if the functionname is not in the string hashtable it is not in any
program so no search is needed.

/Johan

p.s
    I'm not trying to start a 'my mud is better than yours'. As so many have
    said before some like a flexible and powerful language others like one 
    that is simple and easy to learn. How good the resulting mud is depends
    more on the people making the objects than the language used.
d.s
--
Johan Andersson           | "You don`t have conversations with microprocessors
Chalmers, Sweden          | you tell them what to do, and then you helplessly
Email:                    | watch the disaster when they take you literally."
d8andjo@dtek.chalmers.se  |	Sah`ot in David Brins "Startide Rising"
Newsgroups: rec.games.mud