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

[Daniel.Harman at barclayscapital.com]

> -----Original Message-----
> From: Chris Dern [mailto:cdern at home.com]
> [Justin Rogers]:
>> [Derek]:
 
>>> Been pondering multiple ways to solve the issue of Heap
>>> management and the string issue is a thorn in my side.
 
>> If you'd like more information on how we actually declare the
>> string space and grow and shrink it as strings are added let me
>> know and I can probably get the information.

> I actually would be interesting in knowing more about your
> implementation and the impetus behind your design choices. What
> guaranties does the CLR make for construction time on a string? 
> I'm guessing a long running service with a collection of strings,
> could slowly impact the time to find a string.  I'm guessing you
> implement some sort of hash table of pointers into the linear
> memory area. Can you provide what (i'm guessing there are lots of
> them) implementation optimizations you do/can make given an
> immutable string?

This is just my take on the topic :)

They've essentially gone down the same road as Java for strings, and
the over-riding reason for this appears to be simplicity of ensuring
thread-safety. Of course having immutable strings can cause a lot of
performance headaches. Especially when you have a garbage collector
based memory management system. You end up with an awful lot of
discarded objects if you want to change the strings much - only last
week, I had to spend several hours optimising a java program so that
the GC didn't get overwhelmed with discarded objects. I had to do a
number of cheesy fixes such as disable the logging messages, remove
my use of iterators and replace them with for loops etc. etc. The
problem tends to only manifest in tight loops, but seeing as I was
writing a message bridging system, it was a serious problem.

In java at least you shouldn't reuse the Stringbuffer objects
either. If I recall correctly, Java Stringbuffers grow, but they
don't shrink :) This is a real problem if you are using a string
buffer that has grown a lot, as when you copy it to a string, it
copies the whole buffer, not just the bit you think is
populates. You then end up with some very large padded strings.  So
you end up having to create lots of string buffer objects, which
takes you back to the first problem I mentioned! (That last bit
about copying the whole buffer not just the data you think is in it,
I am 98% sure is accurate, but I don't have time to check for now,
and its how I remember it).

Anyway, I'm not a big fan of the GC paradigm for performance based
apps for reasons such as this :) Same with immutable strings, sure
you don't have to understand object syncronisation properly, but the
overhead is ugly.

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