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

Time Complexity: HashMap Implementation from Scratch

O(k + n/m)

Understanding Time Complexity

When building a HashMap from scratch, it is important to understand how fast it can add, find, or remove items.

We want to know how the time to do these actions changes as the number of stored items grows.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

#define SIZE 100

typedef struct Node {
    char* key;
    int value;
    struct Node* next;
} Node;

Node* hashmap[SIZE];

unsigned int hash(char* key) {
    unsigned int hash = 0;
    for (int i = 0; key[i] != '\0'; i++) {
        hash = (hash * 31) + key[i];
    }
    return hash % SIZE;
}

void put(char* key, int value) {
    unsigned int index = hash(key);
    Node* newNode = malloc(sizeof(Node));
    newNode->key = key;
    newNode->value = value;
    newNode->next = hashmap[index];
    hashmap[index] = newNode;
}
    

This code adds a key-value pair to a simple HashMap using chaining for collisions.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: The loop inside the hash function that processes each character of the key string.
• How many times: Once per character in the key, so proportional to key length.
• Secondary operation: Traversing the linked list at hashmap[index] when searching or inserting (not shown here but relevant for get/remove).
• How many times: Depends on number of items in that bucket (collision chain length).

How Execution Grows With Input

The time to compute the hash grows with the length of the key, which is usually small and constant.

Inserting is fast if the bucket has few items, but if many keys collide, the linked list grows and operations slow down.

Input Size (n)	Approx. Operations
10	~10 hash steps + short list traversal (few items)
100	~10 hash steps + longer list traversal if collisions increase
1000	~10 hash steps + possibly long list traversal if many collisions

Pattern observation: Hashing cost stays about the same, but collision chains can grow, making operations slower if the table is too small.

Final Time Complexity

Time Complexity: O(k + n/m)

This means time grows with key length k plus average items per bucket n/m, where n is total items and m is bucket count.

Common Mistake

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

[OK] Correct: If many keys collide, linked lists grow and operations slow down, so time depends on how well the hash spreads keys.

Interview Connect

Understanding how HashMaps work under the hood helps you explain trade-offs and choose the right data structure confidently.

Self-Check

"What if we increased the number of buckets (SIZE) as the number of items grows? How would the time complexity change?"

Practice

1. What is the main purpose of a hash function in a HashMap implementation?

easy

A. To sort the keys in ascending order

B. To store values in a linked list

C. To convert a key into an index for storing the value

D. To delete keys from the HashMap

Solution

1. Step 1: Understand the role of a hash function

   A hash function takes a key and converts it into a number (index) that tells where to store the value in the HashMap's internal array.

2. Step 2: Compare other options

   Sorting keys or deleting keys are not the job of the hash function. Storing values in a linked list is a collision handling method, not hashing.

3. Final Answer:

   To convert a key into an index for storing the value -> Option C

4. Quick Check:

   Hash function = key to index [OK]

Hint: Hash function maps keys to array indexes fast [OK]

Common Mistakes:

• Thinking hash function sorts keys
• Confusing hash function with collision handling
• Believing hash function deletes keys

2. Which of the following is the correct way to declare a simple HashMap structure in C that stores integer keys and values?

easy

A. typedef struct { int key; int value; } HashNode;

B. typedef struct { char* key; int value; } HashMap;

C. typedef struct { int key; int value; } HashMap;

D. typedef struct { int key; int value; HashNode* next; } HashMap;

Solution

1. Step 1: Identify the basic node structure

   A HashMap stores key-value pairs. A node with int key and int value is a basic unit, so HashNode struct is correct.

2. Step 2: Check other options

   typedef struct { char* key; int value; } HashMap; uses char* key which is not integer keys. typedef struct { int key; int value; } HashMap; names the struct HashMap but it's actually a node. typedef struct { int key; int value; HashNode* next; } HashMap; adds a pointer for chaining but names it HashMap, which is confusing.

3. Final Answer:

   typedef struct { int key; int value; } HashNode; -> Option A

4. Quick Check:

   Node struct with int key and value = typedef struct { int key; int value; } HashNode; [OK]

Hint: Node struct holds key and value pairs [OK]

Common Mistakes:

• Confusing node and map struct names
• Using wrong key types
• Missing pointer for chaining in basic struct

3. Given the following code snippet for inserting keys into a HashMap with size 5, what will be the index for key 12?

int hash(int key) {
    return key % 5;
}

int index = hash(12);
printf("%d", index);

medium

A. 4

B. 2

C. 3

D. 1

Solution

1. Step 1: Apply the hash function to key 12

   The hash function returns key % 5. For key 12, 12 % 5 = 2.

2. Step 2: Confirm the printed index

   The code prints the index, which is 2.

3. Final Answer:

   2 -> Option B

4. Quick Check:

   12 % 5 = 2 [OK]

Hint: Modulo operator gives index in hash function [OK]

Common Mistakes:

• Calculating 12 % 5 incorrectly
• Confusing modulo with division
• Ignoring hash function logic

4. Consider this buggy code snippet for inserting a key-value pair into a HashMap with chaining:

void insert(HashNode** table, int size, int key, int value) {
    int index = key % size;
    HashNode* newNode = malloc(sizeof(HashNode));
    newNode->key = key;
    newNode->value = value;
    newNode->next = NULL;

    if (table[index] == NULL) {
        table[index] = newNode;
    } else {
        table[index]->next = newNode;
    }
}

What is the main problem in this code?

medium

A. It overwrites the existing chain instead of appending correctly

B. It does not handle memory allocation failure

C. It uses wrong hash function

D. It does not set the key and value fields

Solution

1. Step 1: Analyze insertion logic for chaining

   If the bucket is empty, it sets the new node. Otherwise, it sets table[index]->next = newNode, which overwrites the existing next pointer, losing the chain.

2. Step 2: Identify correct chaining method

   To append, it should traverse to the last node in the chain and then add the new node, not overwrite the first node's next pointer.

3. Final Answer:

   It overwrites the existing chain instead of appending correctly -> Option A

4. Quick Check:

   Chaining requires appending, not overwriting [OK]

Hint: Traverse chain to append new node, don't overwrite next [OK]

Common Mistakes:

• Ignoring chain traversal
• Assuming single node per bucket
• Not checking for NULL before insertion

5. You want to implement a HashMap from scratch in C that supports integer keys and values, handles collisions using chaining, and dynamically resizes when load factor exceeds 0.7. Which of the following steps is NOT necessary for this implementation?

hard

A. Resize the internal array and rehash all keys when load factor is high

B. Create linked lists at each bucket to handle collisions

C. Implement a hash function to convert keys to indexes

D. Sort the keys in each bucket to speed up search

Solution

1. Step 1: Understand necessary components of HashMap

   A hash function, chaining with linked lists, and resizing with rehashing are all essential for correct and efficient HashMap behavior.

2. Step 2: Evaluate sorting keys in buckets

   Sorting keys in buckets is not required because chaining uses linked lists and search is done by traversing nodes. Sorting adds unnecessary overhead.

3. Final Answer:

   Sort the keys in each bucket to speed up search -> Option D

4. Quick Check:

   Sorting buckets is unnecessary in chaining [OK]

Hint: Chaining uses linked lists; sorting buckets is extra work [OK]

Common Mistakes:

• Thinking sorting improves chaining search
• Ignoring rehashing on resize
• Skipping collision handling