Re: Poll for information

From: Daniel A. Koepke (dkoepke@circlemud.org)
Date: 08/22/01


On Tue, 21 Aug 2001, George Greer wrote:

> I mainly want the numbers to determine the cost of adding 1/2/4-bytes
> to all object data structures.  I haven't examined either possibility
> mentally beyond what I've described in my e-mails.

I think it's safe to say that even a single byte counter will be fine for
all of the necessary counting purposes, but a short int counter might be
preferable just for coverage.

Memory use, I think, is not an issue, here.  With a 2-byte counter and
5000 unique objects, we're adding an overhead of roughly 10kB.  If the
bare object structure, without the counter, is 128 bytes (and it's
probably not, I didn't bother to count), then we're using roughly 640kB of
memory for the structures of these 5000 unique objects.  With the counter,
we're using 650kB, which is not a significant memory loss.

Adding duplicates to the equation, we see how we end up saving memory in
most conceivable situations.  Consider if we had 750 duplicates in lists
throughout the world of some of the 5000 objects.  This means that without
the counter, we're using an additional 96kB in memory for structures for a
grand total of 736kB.  With the counter, we're still using 650kB.

750 duplicates with 5000 unique objects (5750 total objects in the game)
assumes only 15% of the objects in the game are non-unique within their
list.  I'm not sure how steep this number is.  However, a quick bit of
math shows that even assuming only 2% (and even less) of the objects in
the game are duplicated in their list, we still end up with a slight
savings.

CPU considerations are never too great when it comes to CircleMUD, but
just to make a point of the overall superiority of this method, I'll
mention that the cycles used in comparing for combination and copying for
splitting out are recovered in having smaller lists to iterate.  We could
even further recoup cycles by adding a function or macro to move an object
between two lists so that no temporary would have to be instantiated as
the object is removed from one list with obj_from_X() and placed into
another with obj_to_X().  Compare:

Old-style.  Rendered incompatible by the changes necessary to make the
list reference counting work.

  obj_from_char(obj);
  obj_to_obj(obj, cont);

New style #1.  Works, but may construct an object on obj_from_char() that
is then passed to obj_to_obj() only to be destroyed as a duplicate.

  obj = obj_from_char(target);
  obj_to_obj(obj, cont);

New style #2.  Uses a special function intended for moving an object
between lists so that an object is only ever constructed when one needs to
be.  With a macro, we might be able to write something that operates on
any of the lists in a more generic fashion (much like REMOVE_FROM_LIST).
The previous method can be kept in case someone can think of a reason to
remove an object from a list, perform some calculations, and then add it
back into some list.

  obj_from_char_to_obj(target, cont);

All of this requires considerable alterations to the infrastructure of
CircleMUD and should be carefully weighed and considered before adopted in
any way.


-dak

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/06/01 PST