[MUD-Dev] [TECH] String Classes, Memory Management, and Fragmentation

Sean Kelly sean at ffwd.cx
Tue Jul 10 08:54:49 CEST 2001


From: "Derek Licciardi" <derek at elysianonline.com>

> I was wondering if someone from the MMORPG dev teams, or from the
> large scale MUD dev teams would answer a question for me.  How do
> you guys handle Strings in game and the associated heap
> fragmentation of dynamically allocated string classes?  Is anyone
> using third part Heap managers or replacement libraries?  Are you
> using fixed string classes?  Are you sharing strings for common
> objects/mobs?

This obviously depends a lot on the language you're using.  Were I
using C++, I would use std::string, possibly with a custom allocator
(though I don't see this as being neccessary).  Heap managers are
platform-dependent, but they're an obvious option.  It's rare that I
find it neccessary to explicitly allocate memory on the heap, but if
you're worried about heap fragmentation, you can override operator
new and delete to cache objects for reuse.  I played with one design
that stored all message objects in a central repository and clients
just borrowed them when needed.

One other advantage of std::string is the small string optimization.
Most implementations include a small static array for storing short
strings to avoid the performance hit associated with malloc/new.
This also obviously means that there is no heap fragmentation.
Finally, you could set a max message size and store everything in
fixed-size arrays.

I would think that sharing strings has more to do with reducing
memory overhead than heap fragmentation.  Older implementations of
std::string are resource-counted, but this design wreaks havoc with
multithreading, so everyone is moving away from it.  Get a good,
recent implementation of the STL (SGI, STLPort, Dinkumware 3.08) and
get comfortable with it.


Sean

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list