# Operators

(eostrom@k2.ccs.neu.edu)
Sat, 20 Apr 1996 15:55:15 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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.