Subject: Suggestion for 1.8.0

From: Bob Green <[email-masked]>
Date: Wed, 13 Oct 1993 02:37:18 -0700

Hi, 

I've been playing MOOs for some time and in order to improve my coding
skills I compiled up a server for my Linux box (386SX-25 8Mb memory).
With the LamdaCore DB, it hogs all the memory on the system, and if I
forget the server's running and do anything else, the system just about 
drops dead :( In the past I've tried various other servers on my Linux box
and none of them hog memory in the way that MOO does. I know there are
good reasons for reading the entire DB into memory, but I find myself
asking if those reasons are good enough. Many people now run unix-like
systems on 386 and 486 PCs. Here are a few pros and cons for an object
cache.

Pros for an object cache:

   o  Allows the admin to control the memory usage of the server better.

   o  On slower machines, the server will start much quicker.

   o  Could be used to obtain statistics about what objects are
      used, and how much. (I suppose we could do that with the current
      arrangement).

Cons for an object cache:

   o  When an object is not in the cache, it takes a small amount of time
      to retrieve it. Hopefully this would be negligable.

   o  Someone has to write it !

   o  Not entirely necessary on a fast machine with loads of memory.

There are probably other pros and cons as well...

I've heard the argument that its the OSs job to handle memory, but I feel 
we should at least try to help it a bit :)

Oh, I'd be happy to have a go at writing the beast if its felt to be a 
good idea. In fact, I'll probably have a go anyway, since I'll have to
take it off my Linux box otherwise, and I really don't want to do that !

Anyone have any thoughts about this ?

-Bob

| Bob Green          Inmos Ltd, Bristol       [email-masked]
|                                         or  [email-masked]        
|The opinions above are the rantings of a madman and therefore could
|not possibly reflect Inmos policy.

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 13 Oct 1993 10:13:22 -0700

> Date:	Wed, 13 Oct 1993 02:37:18 -0700
> From:	Bob Green <[email-masked]>
> 
> ... pros and cons of an `object cache' ...

As long-time readers of this list are aware, release 1.9.0 of the server will
maintain the database on disk.  The code to implement this well for a system
with the programming generality of MOO is much more complex, though, than most
people appreciate; it is certainly not something one might toss off in a
weekend or two.  The performance of a MOO system that, for example, used whole
objects as the finest grain of disk access would not be acceptable, even though
such an approach has been used successfully in several much simpler systems,
such as TinyMUCK (I think).  We use the data structuring capabilities of MOO
far too heavily for this to work out well; there are many cases of single
properties that are 10s, 100s, or even 1000s of kilobytes in size and the
disk-basing system should support their use properly.  There are also objects
like Mr. Spell and the player-name database that include many hundreds or
thousands of modest-sized properties; swapping all of them into memory whenever
the object is touched would be counterproductive.

I guess my points here are two: disk-basing is coming and it isn't simple to do
a good job of it.  Remember, the disk-basing implementation must support
databases and user demands like LambdaMOO's, not just the much smaller MOOs
that several other folks are running.

	Pavel

---

From: Jay Carlson <[email-masked]>
Date: Wed, 13 Oct 1993 16:13:00 -0700

> As long-time readers of this list are aware, release 1.9.0 of the
> server will maintain the database on disk.

Long-time readers may remember a different number for this too... :-)

> The code to implement this well for a system with the programming
> generality of MOO is much more complex, though, than most people
> appreciate; it is certainly not something one might toss off in a
> weekend or two.

> The performance of a MOO system that, for example, used whole
> objects as the finest grain of disk access would not be acceptable,
> even though such an approach has been used successfully in several
> much simpler systems, such as TinyMUCK (I think).  We use the data
> structuring capabilities of MOO far too heavily for this to work out
> well; there are many cases of single properties that are 10s, 100s,
> or even 1000s of kilobytes in size and the disk-basing system should
> support their use properly.  There are also objects like Mr. Spell
> and the player-name database that include many hundreds or thousands
> of modest-sized properties; swapping all of them into memory
> whenever the object is touched would be counterproductive.

MOO programmers have been rather good at designing objects and data
structures that fit well into the operating model of the server.
$generic_db is a wonderful example of this; it moves much of the task
of lookup from verbs into the server's (hopefully) more efficient C
code.  When the server copied values on reference, parts of the core
were designed to make as few references to lists as possible,  and
instead use primitives like `in' and for-loops to make the server do
as much work as possible for each reference.

One particular constraint we've had for a while is limited creation of
objects (raise your hand if you've refered to 13.2.116.36:8888 as
QuotaMOO).  This led to a culture where the number of objects in a
project was far more important than the actual resource usage, or more
importantly, the reusability and encapsulation of information.  I
would argue that building huge properties is NOT using the data
structuring capabilities of an object-oriented MUD.

If the server changed the costs of certain kinds of operations,
$player_db and $spell would adapt.  If the server was diskbased at an
object-grained level, this would be further encouragement for
object-oriented MOO systems (I'm thinking of object-intensive mail and
features specifically) to grow.

This is assuming we can deal with the quota problem.

> I guess my points here are two: disk-basing is coming and it isn't
> simple to do a good job of it.  

Granted.  But people have counted on diskbasing showing up in the
short-term before, made plans based on this, and they've lost big.

> Remember, the disk-basing implementation must support databases and
> user demands like LambdaMOO's, not just the much smaller MOOs that
> several other folks are running.

Um, no, it doesn't.  There's a fairly large user community out there
that doesn't have control of a state-of-the-art machine to run on.  I
don't see how supporting these people is a loss.

I'll take this as a statement of one of your design goals for your
implementation of diskbasing: must serve the LambdaMOO database.  This
sounds reasonable, except people have been discouraged from doing
their own work on the server to aid `the other MOO community'.

Jay Carlson
[email-masked]    [email-masked]

Flat text is just *never* what you want.   ---stephen p spackman

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 13 Oct 1993 18:45:10 -0700

> Date:	Wed, 13 Oct 1993 16:13:00 -0700
> From:	Jay Carlson <[email-masked]>
> 

No comment... :-)

> structuring capabilities of an object-oriented MUD.

I would agree with you, but I would disagree about the true level of
object-orientation in MOO.  Objects aren't scarce because they're expensive, I
claim, but instead because they are the root-set for persistence; if you don't
recycle an object explicitly, it won't go away.  That makes them harder to use
than, say, lists, in many applications, just as C is harder to use in some ways
than a language with a garbage-collected heap.

Objects are also not anonymous; because of the toobj() function's ability to
create handles on objects out of whole cloth, you can't just create an object
and know, because of how carefully you've controlled who you gave its pointer
(or `name') to, that access to that object is restricted.  MOO Objects thus
cannot be used as what OS guys call `capabilities'.

> features specifically) to grow.

Or, put another way, it might leave MOO programmers stuck between a rock and a
hard place.

> don't see how supporting these people is a loss.

It is not that supporting them is a loss; it's that supporting *only* them is.

> their own work on the server to aid `the other MOO community'.

I don't know what to do about this without irreparably branching the MOO
version tree, with two forked versions that never come together again.  For the
needs of LambdaMOO, Jupiter, and Astro-VR, I'm making certain changes and, in
the limit anyway, those changes also help, I hope, the general MOO community.
Given that I'm not being paid to provide a service to the Internet, I have to
give *some* priority to my own personal needs and pressures, don't I?

	Pavel