Performance Profiling

Overview

iOS app performance problems fall into distinct categories, each with a specific diagnosis tool. This skill helps you choose the right tool, use it effectively, and interpret results correctly under pressure.

Core principle: Measure before optimizing. Guessing about performance wastes more time than profiling.

Requires: Xcode 15+, iOS 14+ Related skills: axiom-swiftui-performance (SwiftUI-specific profiling with Instruments 26), axiom-memory-debugging (memory leak diagnosis)

When to Use Performance Profiling

Use this skill when

• ✅ App feels slow (UI lags, loads take 5+ seconds)
• ✅ Memory grows over time (Xcode shows increasing memory usage)
• ✅ Battery drains fast (device gets hot, battery depletes in hours)
• ✅ You want to profile proactively (before users complain)
• ✅ You're unsure which Instruments tool to use
• ✅ Profiling results are confusing or contradictory

Use axiom-memory-debugging instead when

• Investigating specific memory leaks with retain cycles
• Using Instruments Allocations in detail mode

Use axiom-swiftui-performance instead when

• Analyzing SwiftUI view body updates
• Using SwiftUI Instrument specifically

Performance Decision Tree

Before opening Instruments, narrow down what you're actually investigating.

Step 1: What's the Symptom?

App performance problem?
├─ App feels slow or lags (UI interactions stall, scrolling stutters)
│  └─ → Use Time Profiler (measure CPU usage)
├─ Memory grows over time (Xcode shows increasing memory)
│  └─ → Use Allocations (measure object creation)
├─ Data loading is slow (parsing, database queries, API calls)
│  └─ → Use Core Data instrument (if using Core Data)
│  └─ → Use Time Profiler (if it's computation)
└─ Battery drains fast (device gets hot, depletes in hours)
   └─ → Use Energy Impact (measure power consumption)

Step 2: Can You Reproduce It?

YES – Use Instruments to measure it (profiling is most accurate)

NO – Use profiling proactively

• Enable Core Data SQL debugging to catch N+1 queries
• Profile app during normal use (scrolling, loading, navigation)
• Establish baseline metrics before changes

Step 3: Which Instruments Tool?

Time Profiler – Slowness, UI lag, CPU spikes Allocations – Memory growth, memory pressure, object counts Core Data – Query performance, fetch times, fault fires Energy Impact – Battery drain, sustained power draw Network Link Conditioner – Connection-related slowness System Trace – Thread blocking, main thread blocking, scheduling

---

Time Profiler Deep Dive

Use Time Profiler when your app feels slow or laggy. It measures CPU time spent in each function.

Workflow: Record and Analyze

Step 1: Launch Instruments

open -a Instruments

Select "Time Profiler" template.

Step 2: Attach to Running App

1. Start your app in simulator or device
2. In Instruments, select your app from the target dropdown
3. Click Record (red circle)
4. Interact with the slow part (scroll, tap buttons, load data)
5. Stop recording after 10-30 seconds of interaction

Step 3: Read the Call Stack

The top panel shows a timeline of CPU usage over time. Look for:

• Tall spikes – Brief CPU-intensive operations
• Sustained high usage – Continuous expensive work
• Main thread blocking – UI thread doing work (causes UI lag)

Step 4: Drill Down to Hot Spots

In the call tree, click "Heaviest Stack Trace" to see which functions use the most CPU:

Time Profiler Results

MyViewController.viewDidLoad() – 500ms (40% of total)
  ├─ DataParser.parse() – 350ms
  │  └─ JSONDecoder.decode() – 320ms
  └─ UITableView.reloadData() – 150ms

Self Time = Time spent IN that function (not in functions it calls) Total Time = Time spent in that function + everything it calls

Common Mistakes & Fixes

❌ Mistake 1: Blaming the Wrong Function

// ❌ WRONG: Profile shows DataParser.parse() is 80% CPU
// Conclusion: "DataParser is slow, let me optimize it"

// ✅ RIGHT: Check what DataParser is calling
// If JSONDecoder.decode() is doing 99% of the work,
// optimize JSON decoding, not DataParser

The issue: A function with high Total Time might be calling slow code, not doing slow work itself.

Fix: Look at Self Time, not Total Time. Drill down to see what each function calls.

❌ Mistake 2: Profiling the Wrong Code Path

// ❌ WRONG: Profile app in Simulator
// Simulator CPU is different than real device
// Results don't reflect actual device performance

// ✅ RIGHT: Profile on actual device
// Device settings: Developer Mode enabled, Xcode attached

Fix: Always profile on actual device for accurate CPU measurements.

❌ Mistake 3: Not Isolating the Problem

// ❌ WRONG: Profile entire app startup
// Sees 2000ms startup time, many functions involved

// ✅ RIGHT: Profile just the slow part
// "App feels slow when scrolling" → profile only scrolling
// Separate concerns: startup slow vs interaction slow

Fix: Reproduce the specific slow operation, not the entire app.

Pressure Scenario: "Profile Shows Function X is 80% CPU"

The temptation: "I must optimize function X!"

The reality: Function X might be:

• Calling expensive code (optimize the called function, not X)
• Running on main thread (move to background, it's already optimized)
• Necessary work that looks slow (baseline is acceptable, user won't notice)

What to do instead:

1. Check Self Time, not Total Time

   • Self Time 80%? Function is actually doing expensive work
   • Self Time 5%, Total Time 80%? Function is calling slow code

2. Drill down one level

   • What is this function calling?
   • Is the slow code in a library you control?

3. Check the timeline

   • Is this 80% sustained (steady slow) or spikes (occasional stalls)?
   • Sustained = optimization needed
   • Spikes = caching might help

4. Ask: Will users notice?

   • 500ms background work = user won't notice
   • 500ms on main thread = UI stall, user sees it
   • 50ms on main thread per frame = smooth UI (60fps)

Time cost: 5 min (read results) + 2 min (drill down) = 7 minutes to understand

Cost of guessing: 2 hours optimizing wrong function + 1 hour realizing it didn't help + back to square one = 3+ hours wasted

---

Allocations Deep Dive

Use Allocations when memory grows over time or you suspect memory pressure issues.

Workflow: Record and Analyze

Step 1: Launch Instruments

open -a Instruments

Select "Allocations" template.

Step 2: Attach and Record

1. Start your app
2. In Instruments, select your app
3. Click Record
4. Perform actions that use memory (load data, display images, navigate)
5. Stop recording after memory stabilizes or peaks

Step 3: Find Memory Growth

Look at the main chart:

• Blue line = Total allocations
• Sharp climb = Memory being allocated
• Flat line = Memory stable (good)
• No decline after stopping actions = Possible leak (or caching)

Step 4: Identify Persistent Objects

Under "Statistics":

• Sort by "Persistent" (objects still alive)
• Look for surprisingly large object counts:

  UIImage: 500 instances (300MB) – Should be <50 for normal app
  NSString: 50000 instances – Should be <1000
  CustomDataModel: 10000 instances – Should be <100
  

Common Mistakes & Fixes

❌ Mistake 1: Confusing "Memory Grew" with "Memory Leak"

// ❌ WRONG: Memory went from 100MB to 500MB
// Conclusion: "There's a leak, memory keeps growing!"

// ✅ RIGHT: Check what caused the growth
// Loaded 1000 images (normal)
// Cached API responses (normal)
// User has 5000 contacts (normal)
// Memory is being used correctly

The issue: Growing memory ≠ leak. Apps legitimately use more memory when loading data.

Fix: Check Allocations for object counts. If images/data count matches what you loaded, it's normal. If object count keeps growing without actions, that's a leak.

❌ Mistake 2: Not Accounting for Caching

// ❌ WRONG: Allocations shows 1000 UIImages in memory
// Conclusion: "Memory leak, too many images!"

// ✅ RIGHT: Check if this is intentional caching
// ImageCache holds up to 1000 images by design
// When memory pressure happens, cache is cleared
// Normal behavior

Fix: Distinguish between intended caching and actual leaks. Leaks don't release under memory pressure.

❌ Mistake 3: Profiling Too Short

// ❌ WRONG: Record for 5 seconds, see 200MB
// Conclusion: "App uses 200MB, optimize memory"

// ✅ RIGHT: Record for 2-3 minutes, see full lifecycle
// Load data: 200MB
// Navigate away: 180MB (20MB still cached)
// Navigate back: 190MB (cache reused)
// Real baseline: ~190MB at steady state

Fix: Profile long enough to see memory stabilize. Short recordings capture transient spikes.

Pressure Scenario: "Memory is 500MB, That's a Leak!"

The temptation: "Delete caching, reduce object creation, optimize data structures"

The reality: Is 500MB actually large?

• iPhone 14 Pro has 6GB RAM
• Instagram uses 400-600MB on load
• Photos app uses 500MB+ when browsing large library
• 500MB might be completely normal

What to do instead:

1. Establish baseline on real device

   # On device, open Memory view in Xcode
   Xcode → Debug → Memory Debugger → Check "Real Memory" at app launch
   

2. Check object counts, not total memory

   • Allocations → Statistics → "Persistent"
   • Are images, views, or data objects 10x expected count?
   • If yes, investigate that object type
   • If no, memory is probably fine

3. Test under memory pressure

   • Xcode → Debug → Simulate Memory Warning
   • Does memory drop by 50%+? It's caching (normal)
   • Does memory stay high? Investigate persistent objects

4. Profile real user journey

   • Load data (like user does)
   • Navigate around (like user does)
   • Return to app (from background)
   • Check memory at each step

Time cost: 5 min (launch Allocations) + 3 min (record app usage) + 2 min (analyze) = 10 minutes

Cost of guessing: Delete caching to "reduce memory" → app reloads data every screen → slower app → users complain → revert changes = 2+ hours wasted

---

Core Data Deep Dive

Use Core Data instrument when your app uses Core Data and data loading is slow.

Workflow: Enable SQL Debugging and Profile

Step 1: Enable Core Data SQL Logging

Add to your launch arguments in Xcode:

Edit Scheme → Run → Arguments Passed On Launch
Add: -com.apple.CoreData.SQLDebug 1

Now SQLite queries print to console:

CoreData: sql: SELECT ... FROM tracks WHERE artist = ? (time: 0.015s)
CoreData: sql: SELECT ... FROM albums WHERE id = ? (time: 0.002s)

Step 2: Identify N+1 Query Problem

Watch the console during a typical user action (load list, scroll, filter):

❌ BAD: Loading 100 tracks, then querying album for each
SELECT * FROM tracks (time: 0.050s) → 100 tracks
SELECT * FROM albums WHERE id = 1 (time: 0.005s)
SELECT * FROM albums WHERE id = 2 (time: 0.005s)
SELECT * FROM albums WHERE id = 3 (time: 0.005s)
... 97 more queries
Total: 0.050s + (100 × 0.005s) = 0.550s

✅ GOOD: Fetch tracks WITH album relationship (eager loading)
SELECT tracks.*, albums.* FROM tracks
LEFT JOIN albums ON tracks.albumId = albums.id
(time: 0.050s)
Total: 0.050s

Step 3: Profile with Core Data Instrument

open -a Instruments

Select "Core Data" template.

Record while performing slow action:

Core Data Results

Fetch Requests: 102
Average Fetch Time: 12ms
Slow Fetch: "SELECT * FROM tracks" (180ms)

Fault Fires: 5000
  → Object accessed, requires fetch from database
  → Should use prefetching

Common Mistakes & Fixes

❌ Mistake 1: Not Using Relationships Correctly

// ❌ WRONG: Fetch tracks, then access album for each
let tracks = try context.fetch(Track.fetchRequest())
for track in tracks {
    print(track.album.title)  // Fires individual query for each
}
// Total: 1 + N queries

// ✅ RIGHT: Fetch with relationship prefetching
let request = Track.fetchRequest()
request.returnsObjectsAsFaults = false
request.relationshipKeyPathsForPrefetching = ["album"]
let tracks = try context.fetch(request)
for track in tracks {
    print(track.album.title)  // Already loaded
}
// Total: 1 query

Fix: Use relationshipKeyPathsForPrefetching to load related objects upfront.

❌ Mistake 2: Not Using Batching

// ❌ WRONG: Fetch 50,000 records all at once
let request = Track.fetchRequest()
let allTracks = try context.fetch(request)  // Huge memory spike

// ✅ RIGHT: Batch fetch in chunks
let request