I remember spending an entire afternoon profiling a data-processing loop that was stubbornly slow. I had a protocol-oriented design—which is usually the "right" way to do things in Swift—but for some reason, the compiler was treating every single method call as a slow, dynamic lookup. I was using a protocol to abstract different types of data filters, and even though I only had two concrete implementations in my entire project, the app was behaving as if it had a thousand.

protocol DataFilter {
    func process(_ value: Double) -> Double
}

struct LowPassFilter: DataFilter {
    func process(_ value: Double) -> Double { value * 0.9 }
}

struct HighPassFilter: DataFilter {
    func process(_ value: Double) -> Double { value * 0.1 }
}

func applyFilters(data: [Double], filters: [DataFilter]) -> [Double] {
    var result = data
    for filter in filters {
        for i in 0..

On paper, this is clean. In practice, the filter.process call inside that nested loop was a performance killer. I checked the assembly and saw that the compiler was using "witness tables" for every single iteration. It didn't matter that filters only contained LowPassFilter instances; the compiler was playing it safe because it was analyzing the applyFilters function in isolation from the rest of the module.

The Overhead of File-by-File Analysis

By default, the Swift compiler often works on a per-file basis. When it compiles the file containing applyFilters, it knows that DataFilter is a protocol, but it has no idea which concrete types actually implement that protocol in other files. Because it can't be sure, it uses dynamic dispatch. This means it has to look up the function address at runtime, which prevents the compiler from doing something critical: inlining.

Inlining is where the compiler replaces the function call with the actual code inside the function. If the compiler can inline value * 0.9 directly into the loop, the performance gain is massive. But it can't do that if it doesn't know which function is being called until the app is actually running.

Devirtualization via Whole Module Optimization

This is where Whole Module Optimization (WMO) comes in. Instead of compiling Filter.swift, Processor.swift, and Main.swift as separate units, WMO tells the compiler to look at every single file in the module simultaneously before generating the machine code.

When WMO is enabled, the compiler realizes: "Wait, in this entire module, the only types that ever implement DataFilter are LowPassFilter and HighPassFilter." It can then perform devirtualization. It replaces the expensive witness table lookup with a simple check (essentially an if/else or a switch) to see which concrete type is being used. Once it knows the concrete type, it can finally inline the code.

You don't usually write code "for" WMO; you just enable it. In Xcode, this is handled via the Optimization Level setting. While -Onone (Debug) disables WMO to keep compile times fast, -O (Release) enables it by default. If you're seeing weird performance gaps between your debug and release builds, this is often the culprit.

• Without WMO: The compiler sees a DataFilter. It must use a witness table. No inlining is possible.
• With WMO: The compiler sees the whole module, identifies the concrete types, devirtualizes the call, and inlines the logic.

I'll be honest: the trade-off is compile time. Analyzing the whole module takes longer than analyzing one file. That's why you'll notice your "Archive" build takes significantly longer than your "Run" build. It's a price worth paying for the sheer speed boost in the final binary.

📋 Practical Task

Optimizing a High-Frequency Signal Processor

You are building a signal processing library. You have a protocol SignalTransformer and several concrete implementations. Currently, the system is sluggish because it's being tested in a configuration where optimizations are disabled, and the protocol dispatch is creating a bottleneck.

Your Task:

1. Create a protocol SignalTransformer with a method transform(_ input: Float) -> Float.
2. Create two concrete structs, GainTransformer (multiplies by 2.0) and InvertTransformer (multiplies by -1.0), that conform to this protocol.
3. Write a function processSignal(samples: [Float], transformers: [SignalTransformer]) -> [Float] that applies every transformer to every sample.
4. Create a test suite that processes an array of 1,000,000 samples.
5. Run the code in a Debug configuration (Optimization Level: None) and record the time.
6. Switch the Build Settings to Release (Optimization Level: Optimize for Speed [-O]) to trigger Whole Module Optimization and record the time again.

Goal: Observe the performance difference. You should see a significant reduction in execution time once WMO allows the compiler to devirtualize and inline the transform calls.