MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Operators

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 20 Apr 1996 18:55:03 -0400
From: Erik Ostrom <eostrom@k2.ccs.neu.edu>

> 	It is dangerous to draw direct analogies between objects in C++
> and MOO

No kidding.  In addition, it's dangerous to draw direct lessons from C++
into MOO language design.  C++ was designed to satisfy a lot of needs,
including efficient compilation, implementability as a preprocessor for
C (although this probably isn't a factor anymore), and extreme flexibility
of data structures.  MOO was designed to be hackable while the system is
running, safe for many programmers at once, and arguably easy to learn
and use.  These obviously aren't the complete sets of design constraints
for either language; they're intended to give an idea of the differences.

I'm a little worried by all the "We could just do it the way C++ does it"
I've seen lately.  In particular, C++ is an extremely complex language,
and MOO's designers have kept it admirably simple; I think this is a
vital part of its success, and should be kept central in mind.

> 	In MOO, there is a *huge* difference between the overhead for a
> variable and the overhead for an object.  The process of creating an
> object requires that you alter inheretence hierarchies, allocate data
> structures to store information about the object, its built-in properties,
> its list of properties (even if it has none), its verbs, etc.  When you
> recycle an object, you must deallocate all these data structures.
> Furthermore, frequent creation and recycling of objects leaves holes in
> arrays in the server that waste memory.  This is why, for example, the
> $recycler system exists--to avoid at all costs the overhead associated
> with the create()ion and subsequent recycle()ing of an object and avoid
> "holes" in the list of object numbers.

Actually, I believe $recycler was created because the prospect of
six-digit object numbers was deemed unsightly.  (Of course, LambdaMOO
has made it there anyway, but think of the alternative.)  To address
both these alternative histories:

  * The memory cost of a hole in the object array is insignificant now
    (four bytes? something like that) and could be reduced if it turned
    out to be a problem.  If we didn't have $recycler, we'd probably
    have a much sparser object array, with a lot of space wasted; but
    in that parallel universe, the server could presumably have been
    hacked to use a more efficient data structure (trading off speed
    for space).

  * In general, reimplementing in MOO-code something that the server
    does in C is not a great way to improve efficiency.  As far as I
    can tell, $recycler does everything you mentioned that the built-in
    functions do, except for the allocation of the object itself.  The
    difference is, in $recycler, all the control flow _between_ these
    steps is run on a byte-code interpreter; and $recycler adds in
    additional steps (including numerous verb calls) to maintain
    invariants on $garbage objects.  I don't have any empirical data,
    but I'd bet lots of money that the allocation of the object is
    not a significant enough factor to outweigh everything else $recycler
    does.

There are in fact other good reasons to have $recycler; in addition to
the aesthetic pleasure of low object numbers, it in theory allows us
more flexibility--we can put in various permissions checks and side
effects, and in fact it's how we got byte quota (although that's mostly
orthogonal to object reuse).  But I don't think it was for efficiency
reasons.

Not to pick on you, I just felt like it was time to post to MOO-Cows
again.  I imagine yduJ will correct me if I'm wrong.
References:
Home | Subject Index | Thread Index