[DGD] Re: Auto object question

[Ling]

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? 

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, 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.

If you rilly want hard figures, perhaps installing that rusage() patch and
running a quick benchtest might settle things?  (that's what I used to do
when I used an Amylaar driver) 

> 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.

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

  |    Ling Lo of Remora (Top Banana)
_O_O_  Elec Eng Dept, Loughborough University, UK.     kllo at iee.org




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