HashMap Implementation from Scratch in DSA Rust - Time & Space Complexity

Time Complexity: HashMap Implementation from Scratch

O(n)

Understanding Time Complexity

When building a HashMap from scratch, it's important to know how fast it can add and find items.

We want to understand how the time to do these actions grows as we add more items.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

struct HashMap {
    buckets: Vec>,
}

impl HashMap {
    fn insert(&mut self, key: String, value: String) {
        let index = self.hash(&key) % self.buckets.len();
        self.buckets[index].push((key, value));
    }

    fn hash(&self, key: &String) -> usize {
        key.bytes().fold(0, |acc, b| acc.wrapping_mul(31).wrapping_add(b as usize))
    }
}
    

This code shows a simple HashMap with buckets as vectors of key-value pairs. It inserts by hashing the key and adding to the bucket.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Inserting into a bucket vector and searching that bucket when needed.
• How many times: The insert operation hashes once, then adds to a bucket which may require scanning that bucket if searching.

How Execution Grows With Input

As more items are added, the number of buckets stays fixed unless resized, so buckets get longer.

Input Size (n)	Approx. Operations
10	About 1 to 2 steps per insert/search (small bucket size)
100	About 10 steps per insert/search if buckets not resized (bucket size grows)
1000	About 100 steps per insert/search if buckets not resized (long buckets)

Pattern observation: Without resizing, operations grow roughly proportional to how many items share a bucket, which grows as input grows.

Final Time Complexity

Time Complexity: O(n)

This means in the worst case, inserting or searching can take time proportional to the number of items if many keys collide in the same bucket.

Common Mistake

[X] Wrong: "HashMap operations always take constant time no matter what."

[OK] Correct: If many keys end up in the same bucket, operations slow down because the bucket must be searched linearly.

Interview Connect

Understanding how hashing and bucket size affect speed shows you know the trade-offs behind HashMaps, a key skill in coding interviews.

Self-Check

"What if we added automatic resizing and rehashing when buckets get too full? How would the time complexity change?"

Practice

1. What is the main purpose of a HashMap in data structures?

easy

A. To store elements in a queue-like manner

B. To store elements in sorted order

C. To store key-value pairs for fast lookup

D. To store elements in a stack-like manner

Solution

1. Step 1: Understand HashMap functionality

   A HashMap stores data as key-value pairs, allowing quick access by key.

2. Step 2: Compare with other data structures

   Unlike stacks or queues, HashMaps do not maintain order but focus on fast lookup.

3. Final Answer:

   To store key-value pairs for fast lookup -> Option C

4. Quick Check:

   HashMap = key-value fast access [OK]

Hint: HashMap = fast key-value storage [OK]

Common Mistakes:

• Confusing HashMap with sorted structures
• Thinking HashMap stores elements in order
• Mixing HashMap with stack or queue behavior

2. Which of the following is the correct Rust syntax to create an empty HashMap from scratch?

easy

A. let map = HashMap::empty();

B. let map = new HashMap();

C. let map = HashMap();

D. let map = HashMap::new();

Solution

1. Step 1: Recall Rust HashMap creation syntax

   Rust uses HashMap::new() to create an empty HashMap.

2. Step 2: Check other options for Rust correctness

   Options B, C, and D are not valid Rust syntax for HashMap creation.

3. Final Answer:

   let map = HashMap::new(); -> Option D

4. Quick Check:

   Rust HashMap empty = HashMap::new() [OK]

Hint: Use HashMap::new() to create empty map [OK]

Common Mistakes:

• Using constructor syntax like new HashMap()
• Calling HashMap() without ::new()
• Using non-existent methods like empty()

3. Consider this simplified Rust code snippet for a custom HashMap insert method:

let mut map = MyHashMap::new();
map.insert("apple", 3);
map.insert("banana", 5);
map.insert("apple", 7);
println!("{:?}", map.get("apple"));

What will be printed?

medium

A. Some(3)

B. Some(7)

C. None

D. Some(5)

Solution

1. Step 1: Analyze insertions for key "apple"

   First insert sets "apple" to 3, second insert updates "apple" to 7.

2. Step 2: Check the get method output

   Getting "apple" returns the latest value, which is 7, wrapped in Some.

3. Final Answer:

   Some(7) -> Option B

4. Quick Check:

   Last insert value = get output [OK]

Hint: Last inserted value for key is returned [OK]

Common Mistakes:

• Assuming first inserted value remains
• Confusing None with Some value
• Mixing values of different keys

4. Given this Rust snippet for a custom HashMap insert method, what is the bug?

fn insert(&mut self, key: K, value: V) {
    let index = self.hash(&key) % self.buckets.len();
    if self.buckets[index].is_empty() {
        self.buckets[index].push((key, value));
    } else {
        self.buckets[index].push((key, value));
    }
}

medium

A. It does not update value if key exists, causing duplicates

B. It uses wrong hash function signature

C. It does not handle empty buckets correctly

D. It forgets to resize buckets when full

Solution

1. Step 1: Review insert logic for existing keys

   The code always pushes new (key, value) pairs without checking for existing keys.

2. Step 2: Identify consequence of missing update

   This causes duplicate keys in the same bucket, breaking expected HashMap behavior.

3. Final Answer:

   It does not update value if key exists, causing duplicates -> Option A

4. Quick Check:

   Insert must update existing key, not just push [OK]

Hint: Check for existing key before inserting [OK]

Common Mistakes:

• Ignoring key existence before insert
• Assuming push replaces existing entries
• Missing bucket resizing logic

5. You are implementing a custom HashMap in Rust with separate chaining. Which approach best handles collisions and updates existing keys efficiently?

hard

A. Store key-value pairs in a vector at each bucket; on insert, search vector for key to update or append

B. Use a single vector for all keys without hashing; append all pairs sequentially

C. Replace entire bucket vector on each insert without checking keys

D. Use a linked list but never check for existing keys before inserting

Solution

1. Step 1: Understand separate chaining collision handling

   Separate chaining uses a list (vector) at each bucket to store multiple key-value pairs.

2. Step 2: Efficient insert requires checking existing keys

   Before inserting, search the bucket's vector for the key to update value or append if not found.

3. Step 3: Evaluate options

   Store key-value pairs in a vector at each bucket; on insert, search vector for key to update or append correctly describes this approach; others ignore key checks or hashing.

4. Final Answer:

   Store key-value pairs in a vector at each bucket; on insert, search vector for key to update or append -> Option A

5. Quick Check:

   Separate chaining + key check = efficient insert [OK]

Hint: Search bucket vector for key before insert [OK]

Common Mistakes:

• Ignoring key existence in bucket
• Not using hashing for bucket selection
• Replacing bucket data blindly