[DGD] Dynamic inheritance

[Par Winzell]

S. Foley writes:
 > "Risto Karjalainen" <risto.karjalainen at pp1.inet.fi> wrote:
 > 
 > >I've been thinking of possible solutions for dynamic objects. By dynamic
 > >objects I mean objects whose type can be altered arbitrarily on the fly, 
 > >for
 > >example changing a sword into a door, or even making it be both. One
 > >possible solution would be to have an object inherit all the possible type
 > >objects and have flags determine the type(s) of the object, then simply
 > >cloning everything from it. But I think storing data that might never be
 > >used is an outrageous waste of resources.
 > 
 > I had similar reservations about using a single "superclass" object for 
 > these same reasons, but Mr. Winzell was kind enough to quote some skotos 
 > memory usage statistics that have convinced me that this isn't nearly the 
 > resource problem I thought it was going to be.  Perhaps he'd also be kind 
 > enough to post those statistics to this list.

Well, I think 'statistics' is rather too glorious a term for what
I wrote you... I mostly dismissed the consideration as rather less
than urgent, considering the power of modern machines. Marrach has
upwards of 200K objects, and the statedump is about 800 MB. That's
trivially within the reach of the cheapest of disks. Dumping state
to disk does eat up just about as much disk I/O as it's possible to
throw at it, but ATA/100 is a fast, dirt-cheap technology, and IDE
disks are very fast for this sort of thing these days.

On the other hand, probably 95% of that statedump consists of data
associated with 'THING' clones (that's not statistics, by the way,
just a guess). And, if you examine all those 200K clones a little
more closely, you will find that the vast, vast majority of them
are almost completely empty -- unconfigured. This is because we've
implemented data inheritance; if I buy a short sword at the shop,
I get an empty THING clone with a pointer to an 'ur-short-sword',
and any data lookups doing on my sword pass right through it and
become lookups instead on the ur-sword.

So... assuming the vast majority of our objects are THINGs -- and
the vast majority of those are empty -- then obviously the number
of actual global variables in each THING -- as opposed to actual
data contents -- is the most important factor in determining how
much memory the objects use.


 > Instead of having these inheritables contain the data/code
 > directly, you could have each inheritable have a single item of
 > data, a lightweight object pointer. The various functions in the
 > inheritable would pass off responsibility to the lightweight object
 > for handling the calls when necessary and when the object pointer
 > != nil, or do some default processing when it is nil. So, instead
 > of having 300 variables not doing anything in 60 modules for each
 > object, you have 60 object pointers not doing anything.

Yes, precisely. This is my favourite approach to dealing with this
problem as the amount of functionality in each THING increases and
the number of objects approach several million. The traditional
way to solve the problem is to give each THING a single 'property'
mapping and store everything as properties -- but the LWO solution
is much better for most purposes, I think.

The most complex possibility we've been kicking around in Skotos
is a combination of data inheritance and a version of your LWO
idea: a THING has a number of object pointers; one for each major
branch of functionality -- a 'combat configuration' object, one
for shape/race, perhaps, one for clothing, ... and then let each
of these objects also participate in ur-object data inheritance
chains, so that it's very easy to configure an object with basic
building blocks -- you inherit the cow shape/race configuration,
the bovine combat brain, ...

Wesley should find these ideas familiar. :-)


 > First off, I'm not sure the gain (if this gets you any gain) from such a 
 > system would justify the extra overhead (extra call_others, at minimum).  
 > And beyond that, I'm not even sure this would actually end up saving you 
 > resources in the long run.  And I haven't considered whether such a system 
 > is even desireable from a design standpoint, given the limitations of 
 > lightweight objects.

In our cases, it would be a vast gain. I suspect we may well end
up cutting the size of our statedump in half at least if we did
it right now. However, I don't really care about the size of our
statedump at the moment. :-)

A trivial computation: with 250K objects and 32-byte data structs,
each new global variable added to THING will cost you at least 1M
of statedump. Our THING has well over a hundred variables, and a
fair amount of those are also initialized to ({ }) or ([ ]). So
we probably waste upwards of 200 MB. OK, so that's just a quarter.

Anyway... :-)


 > I think you might be better off just burning the extra memory and saving 
 > yourself some unnecessary complexity.

Yes. For now.

Zell
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd