Quality and craft · advanced

Performance and Instruments

Measure, don't guess — the Time Profiler mental model, the memory instruments, and the diagnosis discipline senior interviews probe.

13 min read14 min practice0/2 exercises5 recall cards

By the end you will be able to

Run the diagnosis loop — reproduce, measure on device in release, fix the heaviest thing, re-measure
Read Time Profiler output — self time vs total time — and find the real culprit
Match each symptom (jank, hang, growth, leak) to the instrument that catches it

Guess firstAnswering before you read makes the explanation stick — even when you get it wrong.

The senior interview classic: "users say the app is slow." A candidate answers: "I'd check the code for inefficient loops and optimise them." Why does this answer fail the interview?

The rules of measurement

Three rules before any instrument, because breaking them produces convincing lies:

Profile release builds. Debug builds skip optimisation — the classic lie is a debug profile whose top rows are retain/release traffic and bounds checks that -O deletes outright, sending you off to spend an afternoon "optimising" a function that is already free in the shipped binary. Profile with ⌘I (Product ▸ Profile), which builds Release by default.
Profile on a device — the oldest one you support. The simulator borrows your Mac's CPU and its performance characteristics are fiction. The iPhone your users actually hold is the truth.
Fix the biggest thing first. A profile is a ranked list; resist the interesting-looking third item. Fix #1, re-measure — the list often reshuffles entirely.

Time Profiler: the mental model

Time Profiler does not trace your code — it samples it: ~1000 times per second it records every thread's call stack. It judges how a colleague spends their day by glancing at their desk at random moments: enough glances and the proportions are the truth — though a task finished entirely between glances never appears, which is exactly what sampling can miss. Functions that appear in many samples were running a lot. Two numbers fall out of the aggregation, and telling them apart is the skill:

Total time (inclusive) — samples where the function was anywhere on the stack — it or anything it called.
Self time (exclusive) — samples where it was the function actually executing at the top.

The culprit is high self time. High total with low self is just an ancestor — viewDidLoad "taking 2 seconds" is usually innocent; the leaf under it doing image decoding is guilty. That aggregation is mechanical, and running it yourself demystifies every profile you will ever read:

A Time Profiler in twelve lines — aggregate stack samples into self and total time.

// Each sample: the call stack at that instant, caller-first.
let samples: [[String]] = [
    ["main", "loadFeed", "decodeJSON"],
    ["main", "loadFeed", "decodeJSON"],
    ["main", "loadFeed", "decodeJSON"],
    ["main", "loadFeed", "resizeImage"],
    ["main", "loadFeed", "resizeImage"],
    ["main", "loadFeed", "resizeImage"],
    ["main", "loadFeed", "resizeImage"],
    ["main", "loadFeed", "resizeImage"],
    ["main", "loadFeed"],
    ["main", "updateUI"],
]

var selfTime: [String: Int] = [:]
var totalTime: [String: Int] = [:]

for stack in samples {
    // Top of stack was executing: self time.
    if let top = stack.last {
        selfTime[top, default: 0] += 1
    }
    // Everything on the stack accrues total time.
    for function in stack {
        totalTime[function, default: 0] += 1
    }
}

for name in totalTime.keys.sorted() {
    let total = totalTime[name] ?? 0
    let own = selfTime[name] ?? 0
    print("\(name): total \(total), self \(own)")
}

Read it like the interviewer would: loadFeed has total 9 — it looks like the problem — but self 1. The samples name resizeImage (self 5) as the heaviest actual work, with decodeJSON (self 3) second. The fix conversation starts at image resizing, and "my loadFeed is slow" was true but useless. Every Time Profiler screenshot you will ever read is this arithmetic at scale.

The symptom → instrument table

Symptom	Instrument	What you look for
Scrolling stutters, animations skip	Time Profiler	main-thread self time inside the scroll window
App freezes seconds, maybe killed (`0x8badf00d`)	Hangs	main-thread blocks > 250ms, and what held it
Memory grows and never returns	Allocations	growth across repeated cycles (see below)
Memory grows, objects never freed	Leaks / Memory Graph	retain cycles — the ARC lesson's purple badges
Slow launch	App Launch	work before first frame; what belongs later
"Something is slow" in your domain	os_signpost	your own labelled intervals on the timeline

Two of these deserve their technique named:

The generation loop (Allocations). Suspected leak in a screen: open it, click Mark Generation in the Allocations detail pane, close it, mark again — repeat five times. Healthy screens produce generations that shrink to ~zero after closing; a screen that retains shows persistent growth per generation, and the instrument lists exactly which objects survived. This is the retain-cycle hunt from the ARC lesson, industrialised.

Signposts (your own instrument). The profiler names functions; it cannot name your concepts — "feed refresh", "checkout flow". Signposts put them on the timeline:

let signposter = OSSignposter(subsystem: "com.app.feed", category: "refresh")
let state = signposter.beginInterval("refresh")
defer { signposter.endInterval("refresh", state) }

Now Instruments shows refresh as a labelled bar you can correlate with CPU, memory and hangs — and the same intervals feed automated performance tests (XCTOSSignpostMetric), turning "it feels slower lately" into a CI regression gate.

The main-thread budget

The number behind "jank": at 60Hz the main thread has ~16ms per frame (~8ms at 120Hz ProMotion). Anything on the main thread during scrolling — JSON decoding, image resizing, date formatting, SwiftData fetches — spends that budget. One 40ms decode = two or three dropped frames = the stutter users report.

The fix hierarchy, in order of preference: don't do the work (cache it — next lessons), do it once (memoise, precompute at write time), do it elsewhere (@concurrent / background task, from the actors lesson), and only then do it faster. Interviews reward candidates who reach for "don't" before "faster".

Predict, then runA wrong prediction you have committed to is worth more than a right answer you read.

Complexity is the other half of performance. Same task, two data structures — the operation counts tell the story before any profiler runs. What prints?

// Task: which of 1,000 incoming ids already exist among 10,000 stored ids?
let storedCount = 10000
let incomingCount = 1000

// Strategy A: Array.contains — scans half the array on average per lookup.
let arrayComparisons = incomingCount * (storedCount / 2)

// Strategy B: build a Set once, then constant-time lookups.
let setBuildCost = storedCount
let setLookupCost = incomingCount
let setTotal = setBuildCost + setLookupCost

print("array strategy: \(arrayComparisons) comparisons")
print("set strategy:   \(setTotal) operations")
print("ratio: \(arrayComparisons / setTotal)x")

Check yourself

Launch takes 4 seconds. Time Profiler during launch shows: main total 3.9s; under it setupAnalytics self 1.8s, loadThemeFromDisk self 1.2s, buildInitialView self 0.4s. The lead-level answer?

›

Build the profiler's table

Write the code

Implement heaviest(samples:) — aggregate stack samples into self time and return the functions ranked by it, ties broken alphabetically.

let samples: [[String]] = [
    ["main", "render", "layoutText"],
    ["main", "render", "layoutText"],
    ["main", "render", "drawGlyphs"],
    ["main", "sync", "diffItems"],
    ["main", "sync", "diffItems"],
    ["main", "sync", "diffItems"],
    ["main", "sync"],
]

func heaviest(samples: [[String]]) -> [String] {
    // Rank every function by SELF time (top-of-stack appearances), descending;
    // break ties alphabetically. Include only functions with self time > 0.
    return []
}

for name in heaviest(samples: samples) {
    print(name)
}

Solution unlocks after 3 attempts

›

Spend the frame budget

Write the code

Implement the frame-budget audit: given main-thread tasks per frame, report the total against 16ms and name the single change with the biggest saving.

struct FrameTask {
    let name: String
    let milliseconds: Double
    let movable: Bool          // can this leave the main thread?
}

let perFrame = [
    FrameTask(name: "layout", milliseconds: 3.0, movable: false),
    FrameTask(name: "decode thumbnails", milliseconds: 9.0, movable: true),
    FrameTask(name: "format dates", milliseconds: 4.0, movable: true),
    FrameTask(name: "draw", milliseconds: 2.5, movable: false),
]

func audit(_ tasks: [FrameTask], budget: Double) -> [String] {
    // Line 1: "total <t>ms vs budget <b>ms — DROPPING FRAMES" (or "ok")
    // Line 2: "move '<name>' off main to save <ms>ms" for the LARGEST movable task
    // Line 3: "after fix: <t>ms — ok" (or "still over")
    return []
}

for line in audit(perFrame, budget: 16.0) {
    print(line)
}

Solution unlocks after 3 attempts

⌘Run the loop on a real profile

Take any project (or the toy app from earlier lessons), add a deliberately heavy row to a list — (0..<20000).map { _ in Int.random(in: 0...9) }.sorted() computed in body — and feel the scroll stutter on a device.
⌘I → Time Profiler. Scroll for ten seconds, stop, and find your sort: note the self time concentrated in it, and the innocent ancestors above. Enable "Invert Call Tree" and watch the culprit jump to the top.
Fix it (compute once, store in the model), re-profile, and confirm — the re-measure step is the habit.
⌘I → Allocations on any screen you can open and close. Mark generations across five open/close cycles; if growth persists, take the Memory Graph and find the purple badge.
Wrap one real operation in OSSignposter intervals and find your named bars in the Instruments timeline — correlate one with CPU spikes.

This one needs the real Xcode — the browser runtime cannot model it.

RecallSaved on this device. Never graded.

Close the page and write the diagnosis you would give in an interview for: "our feed scrolls badly on iPhone 12 but fine on 16 Pro, and only after a few minutes of use." Name the instruments in order, what each would show if the cause is (a) main-thread image decoding vs (b) unbounded memory growth, and the first fix for each. Then check yourself against the lesson.

Checkpoint

You can now:

Run the measure-first loop and say why release-on-device is non-negotiable
Read self vs total time and find real culprits under innocent ancestors
Route each symptom to its instrument, including the generation technique
Argue the fix hierarchy from "don't" down to "faster"

Next up: SwiftUI-specific performance — what makes body run, and how to stop it running for nothing.

How well do you know this now? Rating yourself honestly, then being tested on it, is how you find out where your intuition is wrong.