Sorting Stability and When to Use Which Sort in DSA Go - Time & Space Complexity

Time Complexity: Sorting Stability and When to Use Which Sort

O(n log n)

Understanding Time Complexity

Sorting algorithms arrange data in order, but they differ in speed and behavior.

We want to understand how their running time changes as data size grows and when to pick each sort.

Scenario Under Consideration

Analyze the time complexity of different sorting algorithms.

// Example: Bubble Sort
func bubbleSort(arr []int) {
  n := len(arr)
  for i := 0; i < n-1; i++ {
    for j := 0; j < n-i-1; j++ {
      if arr[j] > arr[j+1] {
        arr[j], arr[j+1] = arr[j+1], arr[j]
      }
    }
  }
}

// Example: Merge Sort
func mergeSort(arr []int) []int {
  if len(arr) <= 1 {
    return arr
  }
  mid := len(arr) / 2
  left := mergeSort(arr[:mid])
  right := mergeSort(arr[mid:])
  return merge(left, right)
}

func merge(left, right []int) []int {
  result := []int{}
  i, j := 0, 0
  for i < len(left) && j < len(right) {
    if left[i] <= right[j] {
      result = append(result, left[i])
      i++
    } else {
      result = append(result, right[j])
      j++
    }
  }
  result = append(result, left[i:]...)
  result = append(result, right[j:]...)
  return result
}

This code shows Bubble Sort and Merge Sort, two common sorting methods with different speeds and stability.

Identify Repeating Operations

Look at the loops and recursion that repeat work.

• Bubble Sort: Nested loops comparing and swapping elements repeatedly.
• Merge Sort: Recursion splitting array and merging sorted parts.
• Dominant operation: Comparisons and swaps in Bubble Sort; recursive splitting and merging in Merge Sort.

How Execution Grows With Input

As input size grows, the work done changes differently for each sort.

Input Size (n)	Bubble Sort Operations	Merge Sort Operations
10	About 45 comparisons	About 30 comparisons
100	About 4,950 comparisons	About 664 comparisons
1000	About 499,500 comparisons	About 9,966 comparisons

Bubble Sort grows very fast (square of n), Merge Sort grows slower (n times log n).

Final Time Complexity

Time Complexity: O(n²) for Bubble Sort, O(n log n) for Merge Sort

Bubble Sort gets much slower as data grows; Merge Sort stays efficient even for large data.

Common Mistake

[X] Wrong: "All sorting algorithms are equally fast for any data size."

[OK] Correct: Some sorts like Bubble Sort slow down a lot with more data, while others like Merge Sort handle growth better.

Interview Connect

Knowing sorting speeds and stability helps you pick the right tool for the job and explain your choices clearly.

Self-Check

"What if we used Quick Sort instead of Merge Sort? How would the time complexity and stability change?"

Practice

1. What does it mean when a sorting algorithm is called stable?

easy

A. It keeps the original order of equal elements after sorting

B. It sorts elements faster than any other algorithm

C. It uses less memory than unstable sorts

D. It only works on numbers, not strings

Solution

1. Step 1: Understand stability in sorting

   A stable sort keeps the relative order of items that compare equal the same as before sorting.

2. Step 2: Compare options

   Only It keeps the original order of equal elements after sorting describes this property correctly. Other options describe speed, memory, or data type restrictions, which are unrelated to stability.

3. Final Answer:

   It keeps the original order of equal elements after sorting -> Option A

4. Quick Check:

   Stable sort = keeps equal items order [OK]

Hint: Stable means equal items keep their original order [OK]

Common Mistakes:

• Confusing stability with speed
• Thinking stability means less memory use
• Believing stability depends on data type

2. Which of the following Go code snippets correctly uses the sort.SliceStable function to sort a slice of structs by an integer field Age?

easy

A. sort.SliceStable(people, func(i, j int) bool { return people[i].Age > people[j].Age })

B. sort.Slice(people, func(i, j int) bool { return people[i].Age > people[j].Age })

C. sort.Slice(people, func(i, j int) bool { return people[i].Age < people[j].Age })

D. sort.SliceStable(people, func(i, j int) bool { return people[i].Age < people[j].Age })

Solution

1. Step 1: Identify stable sort usage

   The question asks for stable sorting by Age ascending. sort.SliceStable is the stable function.

2. Step 2: Check comparison function

   The comparison must be people[i].Age < people[j].Age for ascending order.

3. Final Answer:

   sort.SliceStable(people, func(i, j int) bool { return people[i].Age < people[j].Age }) -> Option D

4. Quick Check:

   Stable + ascending = sort.SliceStable(people, func(i, j int) bool { return people[i].Age < people[j].Age }) [OK]

Hint: Use SliceStable with less-than for ascending stable sort [OK]

Common Mistakes:

• Using sort.Slice instead of sort.SliceStable
• Reversing comparison for ascending order
• Mixing stable and unstable sort functions

3. Given the following Go code, what will be the output after sorting?

type Item struct {
  Name string
  Rank int
}

items := []Item{{"A", 2}, {"B", 1}, {"C", 2}}
sort.Slice(items, func(i, j int) bool { return items[i].Rank < items[j].Rank })
for _, item := range items {
  fmt.Print(item.Name, " ")
}

medium

A. A C B

B. B A C

C. B C A

D. C A B

Solution

1. Step 1: Understand sorting criteria

   The slice is sorted by Rank ascending using sort.Slice, which is unstable.

2. Step 2: Analyze order of equal Rank elements

   Items with Rank 2 are "A" and "C". Since sort.Slice is unstable, their relative order may change. The output shows "B" first (Rank 1), then "C", then "A".

3. Final Answer:

   B C A -> Option C

4. Quick Check:

   Unstable sort may change equal items order [OK]

Hint: Unstable sort may reorder equal keys; check output carefully [OK]

Common Mistakes:

• Assuming stable order with sort.Slice
• Mixing up item names and ranks
• Ignoring unstable sort behavior

4. The following Go code attempts to sort a slice of strings stably by length but does not work as expected. What is the error?

words := []string{"cat", "bat", "apple", "dog"}
sort.Slice(words, func(i, j int) bool { return len(words[i]) < len(words[j]) })

medium

A. Using sort.Slice instead of sort.SliceStable causes unstable sort

B. The comparison function should use > instead of <

C. The slice must be converted to []struct before sorting

D. The code is correct and stable by default

Solution

1. Step 1: Identify sorting function used

   The code uses sort.Slice, which is unstable.

2. Step 2: Understand stability requirement

   To sort stably by length, sort.SliceStable must be used instead.

3. Final Answer:

   Using sort.Slice instead of sort.SliceStable causes unstable sort -> Option A

4. Quick Check:

   Stable sort requires SliceStable, not Slice [OK]

Hint: Use SliceStable for stable sorting, not Slice [OK]

Common Mistakes:

• Thinking comparison direction affects stability
• Believing slice type conversion is needed
• Assuming sort.Slice is stable

5. You have a list of employees with fields Name and Department. You want to sort them first by Department alphabetically and then by Name alphabetically within each department, preserving the order of employees with the same name. Which sorting approach is best in Go?

hard

A. Use one unstable sort by Department only

B. Use two stable sorts: first by Name, then by Department

C. Use one stable sort by concatenated Department+Name string

D. Use two unstable sorts: first by Department, then by Name

Solution

1. Step 1: Understand multi-level sorting with stability

   To sort by Department then Name, stable sorts allow sorting by the secondary key first, then primary key.

2. Step 2: Apply stable sorts in correct order

   Sort first by Name (secondary key) stably, then by Department (primary key) stably. This preserves Name order within Departments.

3. Final Answer:

   Use two stable sorts: first by Name, then by Department -> Option B

4. Quick Check:

   Two stable sorts in reverse order = correct multi-level sort [OK]

Hint: Sort by secondary key first, then primary key with stable sorts [OK]

Common Mistakes:

• Using unstable sorts causing order loss
• Sorting primary key first losing secondary order
• Trying one sort on combined keys without stability