Case Analysis & Cost Models

When someone asks "How fast is this algorithm?" the honest answer is: "It depends."

Consider linear search—scanning an array for a target value. If the target is the first element, we find it instantly. If it's the last element, we scan the entire array. If it doesn't exist, we scan everything and find nothing. Same algorithm, same code, vastly different performance.

Saying "linear search is O(n)" captures something important, but it's incomplete. O(n) describes the worst case—what if we have to check every element? But real inputs aren't always worst-case. Sometimes we get lucky.

Case analysis provides the complete picture. Instead of a single complexity number, we characterize how an algorithm behaves across the spectrum of possible inputs: the best luck can bring, the worst that can happen, and what we typically expect.

For any algorithm, performance can vary based on the specific input. Case analysis systematically captures this variation by examining three scenarios:

Best Case (Ω notation):

The minimum resources (time or space) an algorithm requires across all possible inputs of size n.

Best case represents the most favorable input—the scenario where everything aligns perfectly for the algorithm. It answers: "What's the absolute best performance we could hope for?"

Worst Case (O notation):

The maximum resources an algorithm requires across all possible inputs of size n.

Worst case represents the most adversarial input—the scenario that makes the algorithm work hardest. It answers: "What's the absolute worst performance we must prepare for?"

Average Case (Θ notation, typically):

The expected resources an algorithm requires across a probability distribution of inputs of size n.

Average case represents typical performance—what we expect on "normal" inputs. It answers: "What performance should we expect in practice?"

Why three cases matter:

Different contexts demand different analyses:

• Real-time systems (aircraft control, medical devices): Must guarantee worst-case performance—lives depend on it
• Interactive applications (web servers, UI): Average case matters most—users experience typical behavior
• Security-critical systems (cryptography, authentication): Worst case prevents attacks that exploit slow paths
• Optimization: Best case reveals fundamental limits—you can't do better than best case

No single case tells the whole story. Expert analysis considers all three.

What best case captures:

Best case describes the minimum resources an algorithm uses when given the most favorable possible input. It establishes a floor—performance cannot be better than best case.

How to identify best-case inputs:

For any algorithm, ask: "What input would let this finish as fast as possible?"

• Linear search: Target is the first element → Θ(1)
• Binary search: Target is the middle element → Θ(1)
• Bubble sort: Array is already sorted (with early termination) → Θ(n)
• Insertion sort: Array is already sorted → Θ(n)
• Quicksort: Perfect partitions every time → Θ(n log n)

Detailed example: Linear search best case

def linear_search(arr, target):
    for i in range(len(arr)):
        if arr[i] == target:
            return i    # Found it!
    return -1           # Not found

Best case scenario: target == arr[0]

• We check the first element
• It matches the target
• We return immediately
• Total comparisons: 1
• Best-case complexity: Θ(1)

No matter how large the array, if the target is first, we finish in constant time.

Why best case matters:

1. Establishes fundamental limits: If best case is O(n), then average and worst must be at least O(n). Best case bounds everything above it.

2. Optimistic planning: In some systems, best-case behavior is common enough to optimize for.

3. Algorithm comparison: If Algorithm A's best case is O(n) but Algorithm B's best case is O(1), B might be preferred when favorable inputs are common.

When best case analysis is useful:

• Lower bound proofs: Proving that no algorithm for a problem can do better than Ω(n log n) uses best-case reasoning
• Optimistic caching: If best case is O(1) and happens often, caching strategies can exploit this
• Early termination detection: Algorithms like optimized bubble sort can detect sorted arrays in O(n)
• Interactive systems: Best-case responsiveness affects perceived performance

When best case analysis is misleading:

• When best case is rare: Linear search's O(1) best case almost never happens randomly
• When worst case dominates perception: Users remember the one slow query, not the 99 fast ones
• When adversarial inputs are possible: Security contexts can't rely on favorable inputs

What worst case captures:

Worst case describes the maximum resources an algorithm uses when given the most adversarial possible input. It establishes a ceiling—performance cannot be worse than worst case.

Why worst case dominates analysis:

Worst case is the default in computer science for good reasons:

1. Guarantees: Worst case provides a guarantee. "This algorithm never takes more than O(n²) time" is actionable.

2. Safety: Systems must handle worst-case loads. Servers sized for average load crash during peaks.

3. Adversarial thinking: In security, attackers deliberately trigger worst-case behavior. Denial-of-service attacks often exploit slow algorithmic paths.

4. Simplicity: Worst case is often easier to analyze than average case (no probability distributions needed).

How to identify worst-case inputs:

Ask: "What input would make this algorithm work as hard as possible?"

Detailed example: Quicksort worst case

Quicksort partitions an array around a pivot, recursively sorting partitions:

def quicksort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[0]  # First element as pivot
    left = [x for x in arr[1:] if x < pivot]
    right = [x for x in arr[1:] if x >= pivot]
    return quicksort(left) + [pivot] + quicksort(right)

Best case: Pivot consistently divides array in half → T(n) = 2T(n/2) + O(n) = O(n log n)

Worst case: Array is already sorted (or reverse sorted)

• pivot = arr[0] is the smallest (or largest) element
• left = [] (0 elements), right = n-1 elements
• Partition is 0:(n-1), not n/2:n/2
• Recurrence: T(n) = T(n-1) + O(n) = O(n²)

The same algorithm goes from O(n log n) to O(n²) depending on input—a dramatic difference!

When worst case matters most:

1. Real-time systems: Aircraft control software must respond within a deadline regardless of input. Worst-case guarantees are mandatory.

2. SLA-bound services: "99.9th percentile latency < 100ms" is effectively worst-case thinking at the tail.

3. Adversarial environments: Attackers craft inputs to trigger worst-case behavior. Hash table denial-of-service attacks exploit predictable hash collisions.

4. Resource planning: How much memory to allocate? How many servers to provision? Worst case answers these.

The worst-case mindset:

Engineers often think: "But worst case is unlikely!" True—but unlikely events happen. With millions of operations, even 0.01% probability means thousands of worst-case instances. Design for likelihood; prepare for worst case.

What average case captures:

Average case describes the expected resources an algorithm uses over a probability distribution of inputs. Unlike best and worst cases (which are specific inputs), average case is a weighted average across all possible inputs.

The mathematical formulation:

Average Time = Σ (Probability of input I × Time to process input I)

For all possible inputs I of size n.

The critical assumption:

Average-case analysis requires assuming a probability distribution over inputs. Different assumptions yield different results:

• Uniform distribution: Each input equally likely (common assumption)
• Real-world distribution: Inputs follow actual usage patterns
• Adversarial distribution: Attacker chooses inputs to maximize cost

The result depends entirely on what distribution you assume.

Detailed example: Linear search average case

Assume:

• Array has n distinct elements
• Target is equally likely to be any element or not present
• Probability target is element i: 1/(n+1) for each position plus not present

Simplified analysis (target is in array, position uniformly random):

• If target at position 0: 1 comparison
• If target at position 1: 2 comparisons
• ...
• If target at position n-1: n comparisons

Average = (1 + 2 + 3 + ... + n) / n = n(n+1)/2 / n = (n+1)/2 ≈ n/2

On average, we search half the array. Average case is Θ(n)—same as worst case asymptotically, but with half the constant factor.

Including the "not found" case:

If target has 50% chance of being in array:

• 50% × (n/2) + 50% × n = n/2/2 + n/2 = 3n/4

Still Θ(n), but the constant changes with assumptions.

Challenges with average-case analysis:

1. Distribution assumptions may be wrong: Real inputs often aren't uniformly random. If most searches target recently added items, linear search from the end might be better.

2. Mathematical complexity: Average-case analysis requires probability theory. For complex algorithms, the analysis can be extremely difficult.

3. Misleading expectations: Average hides variance. An algorithm with average Θ(n) might take Θ(n²) 10% of the time, causing occasional severe slowdowns.

4. Doesn't guarantee anything: Average is not a bound. Individual operations can vastly exceed the average.

When average case matters most:

• Throughput-oriented systems: If you process millions of queries, total time matters more than any single query's time. Average predicts total.
• Non-adversarial settings: When inputs genuinely come from a known distribution, average case is realistic.
• Amortized contexts: When occasional expensive operations are acceptable, average-like thinking applies.

Let's see how the three cases combine to give a complete picture of algorithm performance.

Visualization: Performance spectrum

Imagine plotting time (y-axis) against different inputs (x-axis, sorted by time taken):

Time
  |
  |           __________________ Worst case ceiling
  |          /
  |         /
  |        /
  |   ~~~~~/~~~~~~~~~~~~~~~~~~~~ Average case (expected)
  |   /
  |  /
  | /
  |/___________________________ Best case floor
  +---------------------------------> Inputs (sorted by time)

Best case is the floor—no input does better. Worst case is the ceiling—no input does worse. Average case is somewhere in between, weighted by input probability.

Case study: Complete analysis of insertion sort

def insertion_sort(arr):
    for i in range(1, len(arr)):
        key = arr[i]
        j = i - 1
        while j >= 0 and arr[j] > key:
            arr[j + 1] = arr[j]
            j -= 1
        arr[j + 1] = key

Best case: Array is already sorted.

• Each element is already in position
• Inner while loop never executes (arr[j] ≤ key immediately)
• Outer loop runs n-1 times, each doing O(1) work
• Best case: Θ(n)

Worst case: Array is in reverse order.

• Each element must move to position 0
• For element i, inner loop runs i times
• Total: 1 + 2 + 3 + ... + (n-1) = n(n-1)/2
• Worst case: Θ(n²)

Average case: Random input (each permutation equally likely).

• On average, element i moves halfway to position 0
• Total: 0.5 × (1 + 2 + ... + (n-1)) = n(n-1)/4
• Average case: Θ(n²)

Complete characterization:

• Insertion sort is O(n²) worst case
• Insertion sort is Ω(n) best case
• Insertion sort is Θ(n²) average case
• Insertion sort is highly efficient on nearly-sorted data

Not all algorithms have different best, average, and worst cases. Understanding what creates variance helps you predict when case analysis matters.

Algorithms with no variance (all cases equal):

Some algorithms do the same work regardless of input:

• Array access: Always O(1)—input doesn't affect index calculation
• Merge sort: Always O(n log n)—always divides in half, always merges n elements
• Matrix multiplication (naive): Always O(n³)—three nested loops, no early exit
• Brute force search: Always O(2ⁿ)—explores all subsets regardless

These algorithms are input-oblivious—their structure doesn't respond to input characteristics.

Sources of case variance:

1. Early termination conditions:

# Variance from early termination
for item in array:
    if item == target:
        return True  # Can exit early!
return False

If target is found early, we stop. If not found, we scan everything. Early termination creates best-case O(1) vs worst-case O(n).

2. Data-dependent branching:

# Variance from branching
if condition_from_input:
    expensive_operation()  # O(n²)
else:
    cheap_operation()      # O(n)

The input determines which branch executes, creating different complexities.

3. Recursive partition quality:

In divide-and-conquer algorithms, how the input divides matters:

• Quicksort with balanced partitions: O(n log n)
• Quicksort with unbalanced partitions: O(n²)

The input directly affects recursion depth and work distribution.

Case analysis isn't academic—it directly guides engineering decisions. Let's see how professionals apply this framework.

Scenario 1: Choosing a sorting algorithm

Problem: You need to sort user-uploaded data. Users sometimes upload already-sorted files.

Analysis:

• Merge sort: Always O(n log n)—predictable but doesn't exploit sortedness
• Quicksort: O(n log n) average, O(n²) worst on sorted data—dangerous here!
• Timsort: O(n) best on nearly-sorted, O(n log n) otherwise—exploits sortedness

Decision: Use Timsort (Python's default) or similar adaptive algorithm. When best case is common, exploit it.

Scenario 2: Web server response times

Problem: Your API must respond in < 100ms for 99.9% of requests.

Analysis:

• Average response time: 20ms—sounds great!
• But 99.9th percentile: 500ms—fails requirement
• Worst case: 2000ms—catastrophic

Decision: Average isn't enough. You need to analyze tail latency (effectively worst case for the tail). Optimize the slow path, not just the common path.

Scenario 3: Hash table design

Problem: Building a cache. Should you use chaining or open addressing?

Analysis:

Decision:

• If inputs are trusted: either works, open addressing saves memory
• If inputs are untrusted: chaining with universal hashing prevents adversarial worst case
• Regardless: monitor load factor to prevent degradation

Scenario 4: Real-time game physics

Problem: Physics simulation must complete in 16ms (60 FPS) every frame.

Analysis:

• Average collision detection: 2ms
• Worst case (many objects clustered): 25ms—frame drop!

Decision:

• Can't size for average—one bad frame is noticeable
• Implement early-out optimizations (spatial partitioning) to improve worst case
• Consider time-slicing: spread work across frames if worst case occurs

Algorithm performance isn't a single number—it's a spectrum. Case analysis provides the framework for understanding this spectrum completely.

What's next:

Worst-case analysis dominates engineering practice for good reasons. The next page explores why worst case is often preferred—examining the engineering, safety, and business considerations that make worst-case thinking the default in professional software development.