inlining and string concatenation

Mon May 1 02:56:00 GMT 2000

Per Bothner wrote:
> What you can do for numbers is stack-allocate a work buffer
> guaranteed to be big enough. I.e. the algorithm is:
> (1) Stack-allocate an array with an element (a pointer plus one bit)
> for each operand.
> (2) Evaluate each operand in order. If the operand is an object,
> leave a pointer to the resulting String in the array of (1). If the
> operand is a primitive, stack-allocate a work buffer guaranteed to
> be big enough, leaving a pointer to the buffer in (1).

That sounds like it would be a very fast implementation, but it would take
some effort to implement. Integer, Double, etc would have to be modified so
that they can toString() into a generic char[] buffer.
The solution I had in mind certainly wouldn't be as good as this, but it is a
lot simpler and still a big improvement over the existing implementation
(which tends to waste a lot of memory, since wasted buffer bytes from the
StringBuffer are never released until the resulting string gets collected).
It also seems to be significantly faster when Strings (as opposed to
primitives and Objects) are being concatenated, and when the total length of
the strings being concatenated is longer than 16.
The only non-trivial change required for this implementation is for the
compiler to figure out how many items need to be concatenated prior to
calling the constructor.
I've attached my implementation, along with a simple test/timer case.
Results:
$ gij --ms=64M StringConcat 1
FastStringConcatenator: 2259ms elapsed. (heap used = 26620K)
$ gij --ms=64M StringConcat 2
Concatenation operator: 4387ms elapsed. (heap used = 40516K)
regards
 [ bryce ]