Why result builders enable DSLs in Swift - Performance Analysis

Time Complexity: Why result builders enable DSLs

O(n)

Understanding Time Complexity

We want to see how the work done by Swift's result builders changes as the input grows.

Specifically, how does building a DSL with result builders affect the number of steps the program takes?

Scenario Under Consideration

Analyze the time complexity of this simple result builder usage.

@resultBuilder
struct SimpleBuilder {
  static func buildBlock(_ components: String...) -> String {
    components.joined(separator: ", ")
  }
}

func makeList(@SimpleBuilder content: () -> String) -> String {
  content()
}

let result = makeList {
  "apple"
  "banana"
  "cherry"
}

This code builds a list of strings using a result builder to combine them.

Identify Repeating Operations

Look for repeated steps that grow with input size.

• Primary operation: Joining all string components into one string.
• How many times: Once per call, but the join processes each component once.

How Execution Grows With Input

As you add more strings inside the builder, the join operation processes each one.

Input Size (n)	Approx. Operations
10	10 joins
100	100 joins
1000	1000 joins

Pattern observation: The work grows directly with the number of items added.

Final Time Complexity

Time Complexity: O(n)

This means the time to build the result grows in a straight line with the number of components.

Common Mistake

[X] Wrong: "Result builders magically make building DSLs instant, no matter how big."

[OK] Correct: Result builders still process each part you add, so more parts mean more work.

Interview Connect

Understanding how result builders scale helps you explain how Swift handles custom DSLs efficiently and clearly.

Self-Check

What if the builder combined components using nested calls instead of joining all at once? How would the time complexity change?