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 greerga@circlemud.org -- +---------------------------------------------------------------+ | 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