Understanding StringUtils.join performance decisions

Question

I was looking at the implementation of Apache Commons' StringUtils.join method and stumbled upon a line I assume is thought for performance but I don't understand why they did it the way it is, with those specific values.

Here's the implementation:

public static String join(Object[] array, String separator, int startIndex, int endIndex) {
    if (array == null) {
        return null;
    }
    if (separator == null) {
        separator = EMPTY;
    }

    // endIndex - startIndex > 0:   Len = NofStrings *(len(firstString) + len(separator))
    //           (Assuming that all Strings are roughly equally long)
    int noOfItems = (endIndex - startIndex);
    if (noOfItems <= 0) {
        return EMPTY;
    }

    StringBuilder buf = new StringBuilder(noOfItems * 16); // THE QUESTION'S ABOUT THIS LINE

    for (int i = startIndex; i < endIndex; i++) {
        if (i > startIndex) {
            buf.append(separator);
        }
        if (array[i] != null) {
            buf.append(array[i]);
        }
    }
    return buf.toString();
}

My questions regard the StringBuilder buf = new StringBuilder(noOfItems * 16); line:

• I assume giving the StringBuilder an initial capacity targets performance so less resizing is needed while building the string. My question is: how much does these resizing operations actually hurt performance? Does this strategy really improve efficiency in terms of speed? (Because in term of space it could even be negative if more space than necessary is allocated)
• Why is the magic number 16 being used? Why would they assume each String in the array would be 16 characters long? What good does this guess do?

Answer 1

16 is a slight over-estimate (presumably based on experience/statistics) of the expected average size of the strings-with-separator.

Pre-allocating enough space to hold the entire result avoids replacing the backing array during execution with a larger (double the size) array and copying over the elements (which is an O(n) operation).

Over estimating, even by quite a bit, to allocate a larger array is worth the cost if it avoids the replacement operation in most situations.

Answer 2

Really... It's not a only 16 as hard coded you say in your Question .

If you look into the definition again. You will found something like this.

bufSize *= ((array[startIndex] == null ? 16 : array[startIndex].toString().length())
                        + separator.length());  
     //16 will only assigned if Object array at position StartIndex contains null.

        StringBuffer buf = new StringBuffer(bufSize); //if null then default memory allocation for String Buffer will be 16 only.

Here StringBuffer will call the constructor which appriviates as

     new StringBuffer(int Capacity);
Constructs a string buffer with no characters in it and the specified initial capacity.

If Object Array contains the element of at index startIndex then default memomy allocation will be length of that Object.

Thank you.

Answer 3

hmm.. StringUtils.join make OutOfMemory Exception in big arrays...; You know this case.