Re: Poll for information

From: George Greer (
Date: 08/22/01

On Wed, 22 Aug 2001, Daniel A. Koepke wrote:

>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.

I was going to look at memory alignment issues before deciding on 1 or 2
bytes.  If there isn't another 'char' in there somewhere we'd be taking
2-bytes anyway so I'd define it as such.  If we overflow a 1-byte counter
we'd just have two (or more) such identical counted objects: no biggie.

>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.

Some numbers I received were 11,964 distinct objects out of a total 20,707
objects. So there are 8,743 duplicates for that particular MUD, 42%.

>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.

112 bytes on x86.  The rest of my calculations from that mail were:

"So if I added 1-byte to every object data it would take an extra
11,964 bytes. But you'd save 970,473 bytes because of the 8,743 obj_data
structures no longer needed.

That doesn't count mobiles who wouldn't likely have any duplicated objects
but it seems the savings just from the players should counter-balance it.
And even at the worst case, the extra 1 byte isn't going to balloon any
memory requirements."

I don't know if the person wants their numbers associated with their MUD or
name, because it was a private e-mail, so I'll keep it anonymous for now.

>Old-style.  Rendered incompatible by the changes necessary to make the
>list reference counting work.
>  obj_from_char(obj);
>  obj_to_obj(obj, cont);

We don't have to make it incompatible.  The object pointer given to the
function could be unlinked with count=1, while a copy (with -1 to the
count) could be put in it's place.  To the view of the function calling
obj_from_char(), that object was removed from the character.  It's more
work to unlink the old one and put the new one in it's place but I think it
would be worth it

>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);

I would prefer making the old-style work and not have separate functions
for every conceivable start and destination combination.

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

Of course.

George Greer

   | FAQ: |
   | Archives: |

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