[MM’s] Tiny Bench Notes — String Formatting Reality Check

The real trade-offs in Java string formatting

Every Java developer has written this:

String result = String.format("Order %s for %s: $%.2f", orderId, customer, amount);

It’s readable. Expressive. Safe. And in most applications — it’s perfectly fine.

But in high-throughput systems — logging, trading platforms, APIs — this line might execute millions of times per second. At that scale, formatting stops being “just formatting.”

It becomes:

CPU cycles
Memory allocations
Hidden abstraction costs

⚡ TL;DR (Quick Recap)

Fastest: Concatenation (+) and StringBuilder (~94–130 ns/op)
Mid-tier: DecimalFormat / NumberFormat with ThreadLocal (~97–160 ns/op)
Slower: String.format() / formatted() (~180–270 ns/op)
Slowest: MessageFormat (~237–315 ns/op)

Why This Still Matters in Modern Java

Java 9+ introduced invokedynamic optimizations for string concatenation. Java 15 added String.formatted() for cleaner syntax. But one thing didn’t change.

Formatting is not free.

Unlike concatenation, formatting involves:

Pattern parsing
Locale resolution
Object allocation
Varargs handling

And those costs show up clearly in benchmarks.

Benchmark Setup

It measures the average execution time per operation in nanoseconds, running in a shared benchmark state, with 2 forks (each doing 1 warmup fork), warming up for 5 iterations of 1 second each, and then measuring over 10 iterations of 1 second each.

Test parameters:

JMH 1.37 on Java 25
JVM: -Xms1g -Xmx1g -XX:+UseG1GC

All implementations follow a simple contract:

@FunctionalInterface
public interface OrderSummaryFormatter {
    String buildOrderSummary(String orderId, String customer, double amount);
}

Hybrid Wins: Concatenation + Targeted Formatting

public class ConcatenationImpl implements OrderSummaryFormatter {

    @Override
    public String buildOrderSummary(String orderId, String customer, double amount) {
        return "Order " + orderId + " for " + customer + ": $" + String.format("%.2f", amount);
    }
}

Results: ~94–109 ns/op

Or with StringBuilder:

public class StringBuilderImpl implements OrderSummaryFormatter {

    @Override
    public String buildOrderSummary(String orderId, String customer, double amount) {
        return new StringBuilder()
                .append("Order ")
                .append(orderId)
                .append(" for ")
                .append(customer)
                .append(": $")
                .append(String.format("%.2f", amount))
                .toString();
    }
}

Results: ~100–130 ns/op

Why they win:

Minimal abstraction
JVM optimizes + aggressively (JEP 280 (Indy String Concatenation))
Limited formatting overhead

Note: String.format("%.2f", amount) is still used here for decimal formatting. The win comes from bypassing full pattern parsing for the string assembly — not from eliminating String.format entirely.

String.format() Is Lying to You About Performance

public class StringFormatImpl implements OrderSummaryFormatter {

    @Override
    public String buildOrderSummary(String orderId, String customer, double amount) {
        return String.format("Order %s for %s: $%.2f", orderId, customer, amount);
    }
}

Results: ~186–268 ns/op

That’s roughly 2–2.7× slower than simple approaches.

Why?

Creates a Formatter
Parses format string every call
Uses varargs
Handles type conversions dynamically

It looks cheap — but it isn’t.

Note: formatted() is purely syntactic sugar over String.format() — "Order %s: $%.2f".formatted(orderId, customer, amount) has identical performance characteristics to String.format(...).

Formatter and MessageFormat: Even Heavier

Formatter — Results: ~215–257 ns/op

public class FormatterImpl implements OrderSummaryFormatter {

    @Override
    public String buildOrderSummary(String orderId, String customer, double amount) {
        StringBuilder sb = new StringBuilder();
        try (Formatter formatter = new Formatter(sb)) {
            formatter.format("Order %s for %s: $%.2f", orderId, customer, amount);
        }
        return sb.toString();
    }
}

MessageFormat — Results: ~237–315 ns/op

public class MessageFormatImpl implements OrderSummaryFormatter {

    private static final String PATTERN = "Order {0} for {1}: ${2,number,0.00}";

    // ThreadLocal to cache MessageFormat per thread (MessageFormat is not thread-safe)
    private static final ThreadLocal<MessageFormat> MESSAGE_FORMAT = ThreadLocal.withInitial(
            () -> new MessageFormat(PATTERN, Locale.US));

    @Override
    public String buildOrderSummary(String orderId, String customer, double amount) {
        return MESSAGE_FORMAT.get().format(new Object[]{orderId, customer, amount});
    }
}

Even worse:

High variance (unstable performance)
Object lifecycle overhead
Array allocation for varargs and internal synchronization/cloning overhead.

These APIs are built for flexibility — not speed.

The Real Trade-off: ThreadLocal Optimization

public class ConcatenationWithDecimalFormatImpl implements OrderSummaryFormatter {

    private static final ThreadLocal<DecimalFormat> DECIMAL_FORMAT =
            ThreadLocal.withInitial(() -> new DecimalFormat("0.00"));

    @Override
    public String buildOrderSummary(String orderId, String customer, double amount) {
        return "Order " + orderId + " for " + customer + ": $" + DECIMAL_FORMAT.get().format(amount);
    }
}

Results: ~98–160 ns/op

Why it helps:

Avoids object creation
Avoids pattern parsing
Removes synchronization issues

But introduces:

ThreadLocal lookup overhead
More complex code

Performance is often limited by correctness constraints, not just speed.

Note: In thread-pooled environments (Tomcat, Spring Boot, etc.), call DECIMAL_FORMAT.remove() after use — or better, use a request-scoped bean. Static ThreadLocals in servlet containers cause classloader memory leaks on redeploy.

String.format vs MessageFormat: The Localization Trap

Here’s where things get interesting. Most developers assume:

“String.format is fine for international apps. It’s not.

Example

double amount = 1234.56;
String.format("$%.2f", amount)

Output:

$1234.56

Now try a different locale:

Locale.setDefault(Locale.GERMANY);

Output:

$1234,56

Decimal separator changes
Currency symbol does NOT adapt
Formatting is inconsistent

Different locales expect different formats.

But String.format():

Doesn’t handle currency properly
Requires manual locale handling
Produces inconsistent results

The Correct Approach: Locale-Aware Formatting

NumberFormat nf = NumberFormat.getCurrencyInstance(Locale.GERMANY);
nf.format(1234.56);

Output:

1.234,56 €

Correct decimal separator
Correct currency symbol
Proper grouping

Decimal Separators: The Silent Bug

Even basic formatting breaks:

String.format("%.2f", 1234.56);

Output:

US 1234.56
Germany 1234,56

If your system:

Exports CSV
Integrates with APIs
Sends financial data

This becomes a data integrity bug, not just formatting.

Final Takeaways

String formatting in Java is deceptively simple. But under the surface, it involves.

Performance trade-offs
Thread-safety concerns
Localization pitfalls

The biggest lessons:

Simple approaches often outperform abstractions
String.format() is convenient—but expensive
Localization requires dedicated APIs, not shortcuts
Thread safety shapes performance decisions
Micro-benchmarks reveal what intuition misses

In the end, this isn’t about shaving nanoseconds. It’s about understanding what your code actually does — when it runs millions of times and across different regions.

You can find all the code on GitHub.

Originally posted on marconak-matej.medium.com.

[MM’s] Tiny Bench Notes — String Formatting Reality Check

The real trade-offs in Java string formatting

⚡ TL;DR (Quick Recap)

Why This Still Matters in Modern Java

Benchmark Setup

Hybrid Wins: Concatenation + Targeted Formatting

String.format() Is Lying to You About Performance

Formatter and MessageFormat: Even Heavier

The Real Trade-off: ThreadLocal Optimization

String.format vs MessageFormat: The Localization Trap

Decimal Separators: The Silent Bug

Final Takeaways

Trending Tags