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

[Kwon Ekstrom]

<disclaimer>This deals mostly with optimizing java strings/etc</disclaimer>

From: <Daniel.Harman at barclayscapital.com>

> 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

You can use the subString method to optimize this problem, simple
remember the length of the buffer you want, and start reusing the
buffer at the first position.  That'll prevent padding a string with
empty characters.

  out = buf.subString(0,len);

That wouldn't save you from the "large" buffer, but it'd cut down
your object reusage.  Also try to keep your defined objects out of
the loop.  Sure you're still generating new objects for the GC to
collect since you're using the new keyword, but it cuts down on some
overhead.

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

It might be an implementation detail... despite the hype, some java
implementations have inconsistencies.

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

The overhead isn't actually all that bad if you use some
optimization.  Small things such as declaring variables outside of
your loop can cut down on overhead.  It won't prevent the "buildup"
of objects, but use only immutable objects when you need an
"immutable" object.  Also, the fact that the StringBuffer doesn't
shrink is a "good" thing.  The processor overhead is greater if
you're constantly copying the buffer to a new char array because
you're constantly shrinking the buffer.

Make use of the ensureCapacity method to generate a char array with
a size greater than necessary to cut down on some of the unwanted
overhead.

I will admit that because Java is an interpreted language it isn't
quite as efficient as a "well" written c or c++ program, but under
most situations, the performance overhead isn't great enough to make
a difference.

You can call the GC directly via the java.lang.Runtime object.
Runtime.getRuntime().gc();

Um, there's an article on how to manipulate the GC using Reference
Objects, I'll post the URL if you're interested, but that's a whole
different ballgame.

-- Kwon Ekstrom

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