RE: $recycler, $garbage, etc

• Date: Tue, 5 Dec 1995 06:29:47 PST
• From:
  Roger Crew <rfc@microsoft.com>

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

• Prev: Re: $recycler, $garbage, etc
• Next: Re: $recycler, $garbage, etc
• Index: MOO-cows
• Thread: MOO-cows