[MUD-Dev] about MOO

[J C Lawrence]

On Sun, 21 Nov 1999 16:12:55 -0500 
Dan Root <dar at thekeep.org> wrote:

> In message <199911201824.KAA31012 at portland.puremagic.com>,
> bruce at puremagic.com writes:

> CoolMUD's database does this, and seems to do a pretty decent job.
> That said, more than something like a mail index, the place you'll
> lose most heavily is on MOO's inheritence.  Most game cores
> (Lambda and JHM both suffer from this) have a fairly deep and
> sometimes rather broad object inheritance trees.  It's possible to
> have a siginificant portion of your cache filled with nothing but
> items that are inherited in your active objects.

I'll note silently that one of the casues of this problem is that
LambdaMOO requires a single rooted inheritance tree.  If you relax
the inheritance constraints to support multiple roots you start
approaching the point of having an inheritance mesh, which while it
can be a devil to compute and manipulate at runtime, can (not
guaranteed) also work aggressively to lower your working set sizes.

> OTOH, it's certainly possible to cache quite a bit and still see a
> significant reduction in active memory usage.  LambdaMOO was using
> upwards of 256 megs of memory at one point, and I'm sure that
> number isn't going down.  If even 1/10th of your objects were
> simultaneously active, and that many more needed for the
> inheritence of the active objects, that's still reducing your
> active memory image by nearly 4/5ths.

Its the old trade-off:

  Do you render secondary copies of all parent object code in child
objects (so that calls to inherited methods are resolved locally)
resulting is huge space wasting objects that pack out your working
set most of whose data content you never touch?

  Or, do you build your inheritance tree at runtime and spend your
time on object lookups and method resolutions only have those
objects in your working set that you actually touch?

Its not an obvious call.

> And that doesn't even begin to deal with things like storing and
> caching things at a per-attribute rather than per-object level,
> which may or may not increase performance.

I went there.  Lookup overheads can be extreme.

> Heck, UberMUD would still be a decent system with the addition of
> a nice core DB.

Exactly!  Well, modulo that bloody permissions system.

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev