21.1 · Measure first: the method, the metrics and the noise
Performance work is mostly about not fooling yourself. A change that feels faster, on a simulator, in a Debug build, once, proves nothing. The method is what keeps you honest.
Mental model. Never change code until you have a number, a way to reproduce it, and a profile that points at the cause. After the change, take the same number again.
The loop
Reproduce, measure, profile, change one thing, measure again, and know which kind of problem you have.
- How do you approach a performance problem, and which kinds of problem are there?
Work in a loop and do not skip steps: 1) reproduce the problem on a stable scenario (a script, a UI test, a fixed data set), 2) pick one metric that defines… - How do you measure performance reliably: what makes numbers lie, and why do percentiles beat averages?
Measurements lie for boring reasons. Debug builds are unoptimised, so Swift code can be many times slower than the Release build users run. The simulator uses…
More in Performance & energy
- 21.2 · Instruments templates, signposts and XCTMetric
- 21.3 · MetricKit, Organizer and a performance culture
- 21.4 · SwiftUI invalidation and long lists
- 21.5 · The costs that show up in profiles: collections, strings, formatters, JSON, images and disk
- 21.6 · Energy: CPU wake-ups, timers, radios, location and thermal state
- 21.7 · App size: thinning, on-demand resources and the binary
- 21.8 · Writing benchmarks you can believe: the optimiser, build settings and growth tests
- 21.9 · Memory you can count: allocations, dirty versus clean pages and decoded images
- 21.10 · The main thread in code: hang watchdogs, actor hops and quality of service
- 21.11 · Launch: lazy initialisation and measuring from process start
- 21.12 · Counting wake-ups: why polling costs energy even when the work is tiny