Performance profiling

Measuring where time and memory go in a running JVM before changing anything.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain why a measurement should come before an optimisation
Record a CPU profile of a running JVM and read the hot path
Spot the optimisation aimed at suspected rather than measured code

In practice

A few lines that show Performance profiling doing its job.

Bash

# record 60 seconds of a running app
jcmd <pid> JFR.start duration=60s filename=/tmp/app.jfr

# or from startup
java -XX:StartFlightRecording=duration=60s,filename=app.jfr -jar app.jar

# open app.jfr in JDK Mission Control: hot methods, allocations, GC pauses

The common mistake

Watch for

Optimising the code you suspect rather than the code the profile shows. Intuition about hot spots is wrong often enough that a measurement should come first.

What to know first

Your roadmap puts these before Performance profiling, unless you already know them.

Garbage collection

How it stays learned

Once a session shows you understand Performance profiling, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

JIT compilation

Previous in the module← JIT compilation