[DGD] Re: Auto object question

[Felix A. Croes]

Ling <K.L.Lo-94 at student.lboro.ac.uk> wrote:

> On Mon, 29 Jun 1998, Jason Cone wrote:
>
> G'dye Sir,
>
> > For the purposes of answering my question, let's assume that the entire
> > code base consists of 2 functions and 1 variable.  This is asinine, I
> > know, but it makes asking the question a lot easier.  My question is
> > this:  Without bringing LPC -> C into the picture, are there any
> > performance gains in having that code reside in the auto object as
> > opposed to another class that has to be explicitly inherited? 

There are several pros and cons to consider.

 - A call to a function in the auto object uses the special CALL_AFUNC
   instruction, which is 3 bytes in size.  Exactly the same functionality
   would be available with the CALL_DFUNC instruction, which takes 4
   bytes.  Thus, programs that call functions in the auto object will
   be slightly smaller.  In the most extreme case, a function that
   consists of nothing but function calls will be almost 25% smaller if
   CALL_AFUNC can be used for every call.  There will be a barely
   measurable performance difference.

   Note that programs larger than 2K are compressed before being saved
   in the swap file, where the compression factor depends on the
   redundancy of the byte code, so the size advantage in the swap file
   would be much less than 25% if the function mentioned above is large
   enough.

 - Inheriting a utility object, which itself does not inherit anything,
   increases the size of the inheriting program with about 16 bytes.

 - Putting everything into the auto object increases the size of the
   working set.  For a single object the difference won't amount to
   much, but a mudlib wholly designed with the idea of keeping the
   working set small will have a performance advantage.


> I was wondering that too coz I currently have lots of neat functions
> which I tend to class into libraries (eg: all string related
> functions go into string.h which gets #include'd by the autobj).
> Would it be a better idea to make that set into a standalone 'library'
> object and produce a header file consisting of #define str_trim(s)
> "/sys/lib/string"->str_trim(s)?

Here you replace a call to an inherited function with a call_other.
A call_other is slower than a local function call, especially if the
first argument is a string (since an additional call_other to the
driver object will be needed to resolve the object name).


>[...]
> > The design problem/issue that I'm running into is that I currently have
> > a subset of functionality in the auto object which works great.  That
> > functionality, however, is not used by every class.  I'd like to extract
> > that functionality into a separate class that other classes can
> > explicitly inherit if the functionality is needed.  As a specific
> > example, I have object inventory and trigger (add_action()-like
> > functions - see previous posts in this list)  functionality in the auto
> > object.  I'd like to extract it because we have several hundred bin
> > commands, soul commands, and verbs that won't ever touch that kind of
> > stuff.  Daemons fall in the same boat, too.  My main concern is, though,
> > that for those objects that <do> use the inventory and trigger
> > functionality, will they take a huge performance hit in
> > speed/overhead/etc in having to explicitly inherit the appropriate class
> > to gain that functionality? 
>
> Dunno.  Don't think it should...  The Amylaar driver cache call_other's
> (at least, I think it does) so I figure DGD oughta do the same.  Something
> like inventory handling would be quite frequently called upon so it would
> stay swapped in/cached/dirty a lot more often than not.

DGD caches call_other, though a very different mechanism is used,
which is actually more similar to the shared string table than
the call_other cache in Amylaar's driver.  However, no amount of
caching is going to make call_other just as fast as a local
function call.

For a different take on "working set", consider the processor cache
vs. main memory, rather than main memory vs. disk storage.  The
Xeon processor has a 1 Mb cache.  Keeping the working set small
enough to fit inside that cache will be an enormous speedup.


> On a completely different tangent:
> Would it be too hopeful to see a future version of DGD support multiple
> binary listening ports?

There is a networking package for DGD which supports this, among other
things.  I recently placed a 1.1.44-compatible version in
ftp://dworkin.simplex.nl/pub/dgd/pkg/ .

Regards,
Dworkin