Merge Sort as Divide and Conquer in DSA Rust - Time & Space Complexity

Time Complexity: Merge Sort as Divide and Conquer

O(n log n)

Understanding Time Complexity

We want to understand how the time taken by merge sort changes as the list size grows.

How does splitting and merging affect the total work done?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

fn merge_sort(arr: &mut [i32]) {
    let n = arr.len();
    if n <= 1 { return; }
    let mid = n / 2;
    merge_sort(&mut arr[..mid]);
    merge_sort(&mut arr[mid..]);
    merge(arr, mid);
}

fn merge(arr: &mut [i32], mid: usize) {
    // merges two sorted halves
}

This code splits the list into halves, sorts each half recursively, then merges them.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Recursive splitting and merging of sublists.
• How many times: The list is split into halves repeatedly until size 1, then merged back.

How Execution Grows With Input

Each split divides the list in half, creating more sublists to sort and merge.

Input Size (n)	Approx. Operations
10	About 40 merges and splits combined
100	About 700 merges and splits combined
1000	About 10,000 merges and splits combined

Pattern observation: The work grows a bit faster than just doubling; it grows roughly by n times log n.

Final Time Complexity

Time Complexity: O(n log n)

This means if the list size doubles, the work grows a bit more than double, because of repeated splitting and merging.

Common Mistake

[X] Wrong: "Merge sort is just like a simple loop, so it should be O(n)."

[OK] Correct: Merge sort splits the list many times and merges repeatedly, so the total work adds up more than a single pass.

Interview Connect

Understanding merge sort's time complexity helps you explain how divide and conquer algorithms efficiently handle large data.

Self-Check

"What if we changed merge sort to split the list into three parts instead of two? How would the time complexity change?"

Practice

1. What is the main idea behind the Merge Sort algorithm in the context of divide and conquer?

easy

A. Select a pivot and partition the array around it

B. Sort the array by swapping adjacent elements repeatedly

C. Build a heap and extract elements in sorted order

D. Divide the array into halves, sort each half, then merge them

Solution

1. Step 1: Understand divide and conquer in Merge Sort

   Merge Sort splits the array into two halves recursively until single elements remain.

2. Step 2: Merge sorted halves

   After splitting, it merges the sorted halves back together to form a sorted array.

3. Final Answer:

   Divide the array into halves, sort each half, then merge them -> Option D

4. Quick Check:

   Divide and conquer = split, sort, merge [OK]

Hint: Remember: split, sort, then merge halves [OK]

Common Mistakes:

• Confusing Merge Sort with Bubble Sort
• Thinking Merge Sort uses a pivot like Quick Sort
• Ignoring the merge step after dividing

2. Which of the following is the correct Rust function signature for a merge sort function that sorts a mutable slice of integers?

easy

A. fn merge_sort(arr: Vec<i32>) -> Vec<i32>

B. fn merge_sort(arr: &mut [i32])

C. fn merge_sort(arr: &[i32]) -> &[i32]

D. fn merge_sort(arr: &mut Vec<i32>) -> ()

Solution

1. Step 1: Identify mutable slice parameter

   Merge sort modifies the array in place, so it needs a mutable slice: &mut [i32].

2. Step 2: Check function return type

   In-place sorting returns nothing, so return type is omitted (unit type).

3. Final Answer:

   fn merge_sort(arr: &mut [i32]) -> Option B

4. Quick Check:

   Mutable slice input, no return [OK]

Hint: Use &mut [i32] for in-place sorting in Rust [OK]

Common Mistakes:

• Using immutable slice &[i32] when mutation is needed
• Returning a new vector instead of sorting in place
• Incorrect return type for in-place function

3. What will be the output of the following Rust code snippet using merge sort on the array [4, 1, 3, 2]?

fn main() {
    let mut arr = [4, 1, 3, 2];
    merge_sort(&mut arr);
    println!("{:?}", arr);
}

fn merge_sort(arr: &mut [i32]) {
    let mid = arr.len() / 2;
    if mid == 0 { return; }
    merge_sort(&mut arr[..mid]);
    merge_sort(&mut arr[mid..]);
    let mut merged = arr.to_vec();
    merge(&arr[..mid], &arr[mid..], &mut merged[..]);
    arr.copy_from_slice(&merged);
}

fn merge(left: &[i32], right: &[i32], merged: &mut [i32]) {
    let mut i = 0;
    let mut j = 0;
    let mut k = 0;
    while i < left.len() && j < right.len() {
        if left[i] <= right[j] {
            merged[k] = left[i];
            i += 1;
        } else {
            merged[k] = right[j];
            j += 1;
        }
        k += 1;
    }
    while i < left.len() {
        merged[k] = left[i];
        i += 1;
        k += 1;
    }
    while j < right.len() {
        merged[k] = right[j];
        j += 1;
        k += 1;
    }
}

medium

A. [1, 2, 3, 4]

B. [4, 3, 2, 1]

C. [1, 3, 2, 4]

D. [2, 1, 3, 4]

Solution

1. Step 1: Trace recursive splitting

   Array splits into [4,1] and [3,2], then further into single elements.

2. Step 2: Merge sorted halves

   Merge [4] and [1] into [1,4], merge [3] and [2] into [2,3], then merge [1,4] and [2,3] into [1,2,3,4].

3. Final Answer:

   [1, 2, 3, 4] -> Option A

4. Quick Check:

   Sorted array = [1, 2, 3, 4] [OK]

Hint: Merge halves step-by-step to get sorted array [OK]

Common Mistakes:

• Confusing merge order causing wrong output
• Forgetting to copy merged array back
• Incorrect base case stopping recursion too early

4. Identify the bug in this Rust merge sort implementation snippet:

fn merge_sort(arr: &mut [i32]) {
    let mid = arr.len() / 2;
    if arr.len() <= 1 { return; }
    merge_sort(&mut arr[..mid]);
    merge_sort(&mut arr[mid..]);
    let mut merged = arr.to_vec();
    merge(&arr[..mid], &arr[mid..], &mut merged[..]);
    arr.copy_from_slice(&merged);
}

medium

A. The base case condition is correct; no bug here

B. The slices passed to merge overlap and cause incorrect merging

C. The merge function is called with immutable slices, but merged is mutable

D. The base case condition should check if mid == 0, not arr.len() <= 1

Solution

1. Step 1: Check base case

   The condition if arr.len() <= 1 { return; } correctly handles arrays of length 0 or 1.

2. Step 2: Verify recursive calls

   Disjoint mutable slices arr[..mid] and arr[mid..] are sorted independently.

3. Step 3: Examine merge

   Immutable borrows of disjoint slices to merge are temporary; writes to separate merged vec. No overlap or borrow issues.

4. Final Answer:

   The base case condition is correct; no bug here -> Option A

5. Quick Check:

   Disjoint slices + temporary borrows = safe [OK]

Hint: Verify disjoint slices and borrow lifetimes; this is correct [OK]

Common Mistakes:

• Ignoring slice borrowing rules in Rust
• Confusing base case condition with bug
• Assuming immutable slices cause errors with mutable writes

5. Given a large array of integers with many duplicate values, how can you modify the merge step in merge sort to optimize performance by reducing unnecessary copying?

hard

A. Skip copying elements when both halves have equal values during merge

B. Avoid merging duplicates by sorting only unique elements

C. Use a stable merge that avoids copying duplicates by referencing indices

D. Count duplicates and merge them as a single element to reduce size

Solution

1. Step 1: Understand stable merge importance

   Stable merge preserves order of equal elements and can optimize by referencing indices instead of copying repeatedly.

2. Step 2: Avoid unnecessary copying of duplicates

   By using indices and stable merge logic, duplicates are merged efficiently without extra copying.

3. Final Answer:

   Use a stable merge that avoids copying duplicates by referencing indices -> Option C

4. Quick Check:

   Stable merge optimizes duplicate handling [OK]

Hint: Use stable merge to handle duplicates efficiently [OK]

Common Mistakes:

• Trying to merge duplicates as single element (loses data)
• Skipping copying equal elements breaks stability
• Sorting only unique elements changes array content