Introduction

Measuring elapsed time in Swift is mostly about choosing the right clock for the job. If you want user-facing wall-clock timing, Date is fine. If you want performance timing for code execution, DispatchTime or another monotonic clock is usually the better choice.

That distinction matters because wall-clock time can jump if the system clock changes, while monotonic uptime-based clocks keep moving forward steadily. For profiling code, steady clocks are safer.

Use DispatchTime for Performance Timing

For timing code execution, DispatchTime.now() is a solid default because it is based on system uptime rather than calendar time.

1import Dispatch
2
3let start = DispatchTime.now()
4
5for _ in 0..<1_000_000 {
6    _ = 1 + 1
7}
8
9let end = DispatchTime.now()
10let elapsedNanoseconds = end.uptimeNanoseconds - start.uptimeNanoseconds
11let elapsedSeconds = Double(elapsedNanoseconds) / 1_000_000_000
12
13print("Elapsed: \(elapsedSeconds) seconds")

This is the kind of timing you want when comparing one implementation with another or checking whether a refactor actually improved performance.

Use Date for General-Purpose Duration Measurement

If you are measuring elapsed time in a user-facing workflow, Date is still useful and very readable.

1import Foundation
2
3let start = Date()
4Thread.sleep(forTimeInterval: 1.5)
5let elapsed = Date().timeIntervalSince(start)
6
7print("Elapsed: \(elapsed) seconds")

This is a good fit for logging task duration, showing how long a download took, or recording timestamps around business logic where nanosecond precision is not the point.

The tradeoff is that Date represents wall-clock time. That is fine for many app-level tasks, but less ideal for precise benchmarking.

Measure Code in Tests

If your goal is repeatable performance checks, XCTest gives you a built-in measurement tool:

1import XCTest
2
3final class PerformanceTests: XCTestCase {
4    func testSortingPerformance() {
5        measure {
6            let values = (0..<10_000).shuffled()
7            _ = values.sorted()
8        }
9    }
10}

This is often better than sprinkling manual timers everywhere because the measurement lives in a test and can be rerun in a controlled way.

It also keeps performance experiments separate from production code, which is a good habit when timing logic is only there for analysis.

Avoid Misleading Microbenchmarks

Timing one tiny loop once is rarely enough to draw a serious conclusion. Modern compilers, CPU caches, and background system work can all distort small measurements.

A more trustworthy pattern is:

• warm up the code path
• run it multiple times
• measure something realistic enough to matter
• compare results under similar conditions

The timer API is only one piece of the problem. The quality of the experiment matters just as much as the clock you pick.

Common Pitfalls

The biggest mistake is using Date for very fine-grained performance timing and then treating the result as precise enough for benchmarking. For that kind of work, a monotonic uptime-based clock is safer.

Another common issue is timing code only once and assuming the number is stable. One run can be dominated by startup effects or unrelated system activity.

It is also easy to benchmark debug builds and draw the wrong conclusion. Measure optimized builds when performance is the real question.

Finally, do not leave ad hoc timing code all over production paths unless it genuinely serves an operational purpose. Use tests or targeted instrumentation instead.

Summary

• Use DispatchTime for precise code-performance timing.
• Use Date for readable general-purpose elapsed durations.
• Use XCTest measure for repeatable performance tests.
• Prefer monotonic clocks for benchmarking.
• Treat the timing setup as part of the experiment, not just the timer call.