Why can't I just use a stopwatch to see which function is faster?

I get this question a lot. It seems intuitive: just wrap your code in a timer, run it, and see which one finishes first. The problem is that timers measure wall-clock time, which is noisy. Your results will change based on whether your MacBook is plugged in, how many Chrome tabs you have open, or if the OS decided to run a background update mid-test.

Big-O notation isn't about seconds; it's about scaling. It describes how the runtime of your function grows as the input size (which we call n) grows. If you have a list of 10 users, a slow algorithm is invisible. If you have 10 million users, the difference between an O(n) algorithm and an O(n²) algorithm is the difference between a fraction of a second and your app hanging for three hours.

How do I actually "calculate" Big-O when looking at my Swift loops?

You don't need a PhD in math to do this. For most of the Swift code you'll write, you just need to count how many times you're iterating over your data. If you have one loop going through an array, that's typically O(n)—linear time.

The "danger zone" is usually nested loops. If you loop through an array, and inside that loop, you loop through the same array again, you've just hit O(n²)—quadratic time. I've seen plenty of juniors accidentally write O(n²) code when trying to find duplicates in a list. Take a look at this:

func hasDuplicates(items: [Int]) -> Bool {
    for i in 0..

If you double the number of items in that array, the work doesn't double—it quadruples. That's why we try to avoid nested loops over the same collection whenever possible.

What's the real-world difference between O(1) and O(n) in Swift collections?

This is where understanding your data structures pays off. In Swift, accessing an element in an Array by its index is O(1). It doesn't matter if the array has ten elements or ten billion; the computer knows exactly where that memory address is and jumps straight to it. That's "constant time."

However, searching for a specific value in an unsorted array is O(n). Swift has to check every single element from the start until it finds a match. Here is the contrast:

let numbers = [10, 20, 30, 40, 50]

// O(1) - Constant time. Instant access.
let secondItem = numbers[1] 

// O(n) - Linear time. We might have to check every item.
let index = numbers.firstIndex(of: 50) 

Pro tip: This is why we use Dictionaries. Checking if a key exists in a Dictionary is O(1) on average. If you find yourself calling firstIndex(of:) inside a loop, you're accidentally creating an O(n²) nightmare. Switch to a Set or a Dictionary instead.

Is O(log n) just academic, or will I actually use it?

It's very real. The classic example is a Binary Search. Imagine you have a sorted list of a million usernames and you're looking for one. A linear search (O(n)) might take a million checks. A binary search (O(log n)) will find it in about 20 checks. It does this by splitting the search area in half with every single step.

You'll see this logic everywhere in high-performance systems. While Swift's standard library handles a lot of this under the hood, knowing that sorting your data first allows you to move from O(n) to O(log n) search time is a superpower when you're optimizing a sluggish app.

📋 Practical Task

Refactoring the Duplicate User Finder

You have been handed a piece of code that checks if a list of User IDs contains any duplicates. Currently, it uses a nested loop, making it O(n²), and it's causing the app to freeze when the user list grows large.

Your Task: Refactor the hasDuplicates function to use a Set. By leveraging the O(1) lookup time of a Set, you should transform the algorithm from O(n²) to O(n) linear time.

struct User {
    let id: String
}

func hasDuplicates(users: [User]) -> Bool {
    // CURRENT O(n^2) IMPLEMENTATION
    for i in 0..

Implement the optimized version and explain in a comment why the Set approach changes the Big-O complexity.