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