Performance Optimization

What you'll learn

Fast software matters — but so does not wasting effort optimizing the wrong thing. This module teaches a disciplined approach: measure, target the real bottleneck, and know which changes actually move the needle.

By the end you'll be able to:

• Measure before optimizing — and know why
• Prioritise the changes that matter most
• Reduce memory pressure and string overhead
• Optimise collections, I/O, and database access
• Use caching, benchmark with JMH, and understand JVM tuning

Measure first

The cardinal rule of performance: measure, don't guess. Developers are famously bad at predicting bottlenecks — the slow part is rarely where you think. Profile the running program (Module 30), find the actual hotspot, fix it, then measure again to confirm you helped.

Algorithmic wins come first

When performance does matter, your algorithm and data structure choices dwarf everything else. Turning an O(n²) loop into O(n log n), or swapping a linear search for a HashMap lookup, can make code thousands of times faster — no micro-optimization comes close:

Memory & strings

Creating fewer objects means less work for the garbage collector (Module 27). The classic example is string building: concatenating with + in a loop creates a new immutable String every iteration — quadratic work. A StringBuilder reuses one buffer:

int n = 100_000;

// ✗ O(n²): each += builds a brand-new String
String s = "";
for (int i = 0; i < n; i++) s += i;

// ✓ O(n): one mutable buffer, appended in place
StringBuilder sb = new StringBuilder();
for (int i = 0; i < n; i++) sb.append(i);
String result = sb.toString();

Collections & I/O

Choosing the right collection (Module 14) is a performance decision: HashMap lookups are O(1) vs O(n) for scanning a list. And I/O — disk and network — is orders of magnitude slower than CPU work, so it's often the real bottleneck. Buffer your I/O (Module 19), batch database queries instead of looping (avoid the "N+1 query" problem), and fetch only the data you need.

Caching

The fastest work is work you don't repeat. Caching stores the result of an expensive operation so subsequent calls are instant. Map.computeIfAbsent is a clean way to cache in memory; at scale, a dedicated cache like Redis serves many servers:

import java.util.*;

Map<Integer, Long> cache = new HashMap<>();

long expensive(int key) {
    return cache.computeIfAbsent(key, k -> {
        // ...slow computation runs only once per key...
        return (long) k * k;
    });
}

Benchmarking & JVM tuning

Micro-benchmarking Java is deceptively hard because of JIT warm-up (Module 27) — naive timing gives wrong numbers. The standard tool is JMH (Java Microbenchmark Harness), which handles warm-up and statistical rigor for you. At the deployment level, JVM tuning — heap size (-Xmx), garbage-collector choice — can matter for high-performance services, but only after your code and algorithms are sound.

Recap & quick check

Great — you can now make code fast the disciplined way. Next up: Module 39 — Packaging, Deployment & Distribution.