[DGD] Re: Out of curiosity...

[Stephen Schmidt]

On Mon, 25 May 1998, Felix A. Croes wrote:
> Previous poster wrote:
> > I was playing with the idea of making a really fat Auto-object. Putting in
> > environment-functions, inventory handling, action handling, all possible
> > string and array functions (strstr, filter_array etc) and all other stuff I
> > want to have easy access to. 
> > I am sure it is a bad idea, but exactly how bad is the idea resource-wise?

> There is an obscure cost associated with functions in the auto object
> that are neither static nor private: all such functions have a cost of
> two bytes a piece in <every> inheriting object's program.  This is also
> true for non-private functions in all other (i.e. non-auto) objects.
> Normally, this is not much of a problem.  However, if you were to have
> 200 such functions in the auto object, every other program in the game
> but that of the driver object would become 400 bytes larger.

Something else that might or might not be a problem is that (if the
DGD internals are similar to MudOS internals in this regard, which 
I don't know) it may increase the time required to look up functions in
the object. One of the points of developing a properties system for
objects, where labels can be set in an object using set ("label", val)
and similarly queried, was to eliminate the many instances of set_short(),
set_long(), set_light(), set_this(), set_that(), set_ad_infinitum() in
the belief that having so many functions might reduce both memory usage
and CPU use in accessing functions. Limited testing that was done
suggested that this might be a fairly large savings in CPU, but that it
was more than offset by the security requirements of the set() function,
because a handful of important data were being controlled that way but
security was invoked on all calls. We came to the conclusion that
it was Good to have properties but Bad to use them for anything
requiring security, but never tried to test or implement that idea.

All of which is a long way of saying that, maybe, having a large
number of functions in every object may slow down the code. Which
leads to the question - is that right or not? Does the CPU required
to access a function in an object increase as the number of functions
defined by the object increased? Or has that been changed? If it does
increase, the loading up the auto object with a lot of functions
might lead to a noticable CPU hit. Or might not. Testing it would
be the only way to find out.

Stephen Schmidt

A general who husbands his reserve until the day following a battle
is commonly, and deservedly, beaten.   
					- Napoleon







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