# $recycler, $garbage, etc

Roger Crew (rfc@microsoft.com)
Tue, 5 Dec 1995 06:29:47 PST

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

    Message-ID: red-45-msg951205222924MTP[01.51.00]000000b9-22521

    >  Is there any reason to "recycle" objects (parent them to $garbage
    and re-use)
    >   other than keeping down max_object()?  Is that benefit really
    anything but an
    >   aesthetic one?

    Deep in the guts of the server is an array [0..max_object()] of
    object pointers.  Whether an object number is in use or not, a slot
    exists in this array.  The larger max_object() is, the bigger this
    array is, regardless of how few objects actually exist.

    So, yes, there is SOME benefit; whether this is a major benefit or even
    worth thinking about at all is a matter of how many unused object ids
    you're planning to have as compared with the overall size of your db.

    It should also be noted that re-using object numbers is something of
    a PREVENTATIVE measure.  Once space is allocated for the object table
    it is never given back, not even if you recycle everything and do
    reset_max_object().
    Thus, the idea is more to prevent the space from being allocated in
    the first place, i.e., by keeping max_object() small enough that
    the server never feels the need for it.

    A basic object is about 16 words (more if it has its own properties,
    verbs, etc...).
    The space taken up by an unused object number is that of a pointer,
    1 word (4 bytes, 32 bits) --- and yes there are machines with 64bit
    pointers, in which case some of these numbers are different, but the
    overall situation is roughly the same, qualitatively.

      max_object() | object pointer array

         #100           400 bytes       basic LambdaCore
         #200           800 bytes
        #3200          ~13 K            JHM
       #12800          ~51 K            LambdaMOO in summer 1991
      #102400         ~400 K            LambdaMOO now
      #409600         ~1.6 Meg          LambdaMOO w/o $recycler (conservative)
     #6553600          ~26 Meg          LambdaMOO w/o $recycler (nutcase)

    To put this in perspective, a small LambdaCore DB probably runs at 3-5Meg
    and LambdaMOO's current DB is ~200Meg.

    If you want a forumula:

      % of db used by objectid array
           == (max_object() / 2500) / db-size-in-Meg

    e.g., max_object()=#10000, 4Meg db => 1% of your db is objectids.
    If this percentage is noticeable
    AND a large fraction of your object number space goes unused,
    then you *do* want to worry about this

    Given the way objects are used in LambdaCore, object pointer
    array size is generally in the noise and it may indeed not
    be worth worrying about --- I don't know of any 4Meg dbs that
    are pushing max_object()=#10000.

    However, one property of small dbs worth keeping in mind is that
    they sometimes grow into large dbs.
    Gauging just where LambdaMOO would be without the $recycler
    and without giving people ANY encouragement to reuse object numbers
    is major-black-art guesswork.  We did, after all, go from #14500
    to #16000 in a single day.  Even the `nutcase' guess is a little
    dangerous.
      "Nobody'll ever need more than 6 million objectids,"
    sounds a little too much like,
      "Nobody'll ever need more than 640K of RAM,"
    for comfort.
    In any case, the nutcase guess would have unused numbers taking up
    about 10% of DB size, rather than 1% as with the conservative guess,
    or the 0.2% that they're actually taking up now.  Never mind that
    at 200Meg, with about that much actual RAM, every last meg hurts.

    Naturally, if you've got novel uses for objects/object-ids that
    require burning through large numbers of them, all bets are off.
    Consider an event system that creates a new object (to be recycled
    shortly thereafter) every time someone enters a room or says
    something:

     .conversation => ~50000 events/hour
                   => ~200K/hour in db growth due to unused object pointers

    Suffice it to say, if you're going to do something like this,
    you'll want to modify the number->object matching in the server
    to use a hash table instead of an array

    (hmm.... compile-time option?  Pavel?  you were looking for things
    to do to fill up your copious free time, right?  :-)

    	Roger