Why String Concatenation in a Loop Is Slow

Direct Answer

A String cannot grow in place. With result += piece, each loop iteration creates another concatenated String and may copy the whole prefix built so far. For many similar-sized pieces, the repeated copying can approach quadratic work. Reuse one StringBuilder across the loop and call toString() after the last append.

Deep Dive & Architecture

Cumulative copying

The Java language defines a runtime String concatenation as producing a String that contains the left operand followed by the right operand. Because the result is immutable, a statement such as text = text + part cannot reserve more room inside the old String. The next value has to contain both the accumulated prefix and the new part.

If ten equal-sized pieces are added, the prefix sizes copied across the loop grow roughly like 0, 1, 2, and so on. The sum of those sizes grows quadratically with the number of pieces. Describing only “many temporary objects” misses the main point: object count grows linearly with loop iterations, while repeatedly copying the expanding prefix is what can make the total character work much larger.

Mutable capacity changes the pattern

StringBuilder represents a mutable sequence. append adds to the same logical builder, and its internal capacity is retained for later appends. Capacity occasionally has to grow and existing content may be copied during that growth, but growth is not required for every piece. This normally gives amortized linear work for assembling the final text. Calling toString() at the boundary produces the immutable value that the rest of the program can safely use.

Providing an estimated capacity can help when the output size is predictable, but guessing a very large value can waste memory. StringBuffer offers synchronized individual operations; it is not the default choice for a builder local to one thread.

Compiler and measurement boundaries

Constant concatenations such as "Java" + " 25" can be evaluated at compile time. For non-constant expressions, the JLS permits compilers to choose an implementation technique, and current javac versions can use StringConcatFactory rather than a literal source-level StringBuilder rewrite. That optimization can handle one expression well, but it does not change the source-level fact that assigning a newly concatenated growing String on every loop pass repeats the work.

Choose the readable + form for small expressions and a reusable builder for iterative assembly. If the code is performance-critical, compare implementations with JMH or application measurements instead of timing one loop with currentTimeMillis().

Code Example

import java.util.List;

class StringLoopDemo {
    static String withPlus(List<String> parts) {
        String result = "";
        for (String part : parts) {
            result += part;
        }
        return result;
    }

    static String withBuilder(List<String> parts) {
        StringBuilder builder = new StringBuilder();
        for (String part : parts) {
            builder.append(part);
        }
        return builder.toString();
    }

    public static void main(String[] args) {
        List<String> parts = List.of("Java", " ", "strings");
        String slow = withPlus(parts);
        String efficient = withBuilder(parts);

        if (!slow.equals(efficient)) {
            throw new AssertionError("The results should match");
        }
        System.out.println(efficient); // Java strings
    }
}

Both methods have the same result. The difference is that withBuilder keeps one mutable builder across every loop iteration.