[DGD] Re: Auto object question

[Kris Van Hees]

On Tue, Jun 30, 1998 at 01:43:51PM +0100, Ling wrote:
> On Mon, 29 Jun 1998, Jason Cone wrote:
> > 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? 
> 
> 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)?

Well, putting code in an include file (.h) is never a good idea, because it
means that code gets actually put into the program for every class which
includes that file.

Using a standalone library object as you call it is alot more efficient, but
contrary to what you express below, its object oriented properties can be
argued, and performance wise it's not on top of the list.

The most obvious way I think to implement this in an OO fashion would be to
write a class with your string functions and to *inherit* it into all classes
that want it.
> 
> Well, so far, my thoughts have gone along the lines of:
> 
> a) it'll be easier to maintain/update on the fly
> b) more object orientated (I think)
> c) looks nice
> d) performance might take a hit
> 
> Point a) is moot given the compile_object() kfun.  b) and c) are
> subjective.  As for d)...  Yesterday, I tried booting and rebooting the
> dgd driver by hand as fast as I could with the thing doing something
> fairly significant inbetween.  It barely registered on 'top'.  (using a
> P166MMX with 64 megs of ram, utterly different story on an Amiga
> 68030/50MHz :)  So my current feeling is to go for tidy code from the
> maintenance point of view.

Point a) is indeed fairly moot, though can become important once you get alot
of these classes.  Again, b) and c) are definitely subjective, thouhh I would
not underestimate b) in view of clean design making it more manageable.

Asfar as d) goes of course... well, with top you definitely will not get any
real useful information about how efficient something is.  But given the rule
that it one should optimize the most inner loops and most often used code
first, you should determine first how often this gets used.  Since it is
string functions in a mud-based environment, I'd say it could be pretty
frequent, so going for a fairly optimized implementation is a good thing.
> 
> 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.

Note though that while call_other() caching happens (as far as I remember,
don't have the code handy right now), that doesn't mean it makes the use
of call_other() as fast as a local call or a call to an inherited class.
Dworkin can shed more light on the path through the code for the three
cases of calls, as far as efficiency goes, I'm sure.  But remember that at
least as far as typechecking goes, for strictly typed code compile-time
checking can be done for functions which are within the current class (and
the classes it inherits), while for call_other() pure runtime typechecking
must be done, since at compile-time the prototype of the recipient of the
call isn't know.

Hope this helps,
Aedil



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