Hash Table Internals - Part 7 - Performant Hash Tables
Hash Tables are designed to give a constant time performance and to do this, it needs to have a large number of slots available. So, which factors decide its performance?
Load Factor
Load Factor is a quantification that makes it simple for us to tell how loaded the Hash Table is, and it is just a simple division of the number of keys and the number of slots in the hash table.
As the load factor increases, the performance of the Hash Table decreases. It happens purely because it takes longer for us to do a slot lookup and find an empty slot to place the key.
The Best Strategy
Every probing strategy or collision resolution strategy has its merit and demerit, and they all perform the best in a certain condition and the worse in others. Let's take a detailed look.
Chained Hashing
Chained Hashing is costly, as it requires us to do a linear traversal of the linked list to find the key we are looking for. As the collisions increase, the lookup time shoots up, degrading the performance.
Chained Hashing is not cache-friendly, as it requires us to do random lookups in the memory while hopping from one linked list node to another.
Double Hashing
Evaluating two hash functions requires extra CPU cycles that could get taxing. Double hashing is also not cache-friendly, as it requires us to jump across the Hash Table to hunt an empty slot.
The optimal strategy is contextual. If the performance of the Hash Table is critical, then we need to experiment, tune, and evaluate the best that fits us.
Lookup Time vs Load Factor
Lookup Time is the most critical metric in evaluating the performance of the Hash Table; when we benchmark Lookup Time vs Load Factor, we would see
领英推荐
Making Chained Hashing cache efficient
Chained Hashing is known for being cache-inefficient, as it requires us to traverse through linked list nodes that may be present across the heap. Can we somehow make it cache efficient?
To make Chained Hashing cache-friendly, we have to ensure that the nodes of the linked list are allocated contiguously instead of randomly. Hence, instead of allocating one node at a time, we allocate the space for 5 nodes (like an array) at a time and then form the linked list out of them.
This would make the linked list leverage the CPU cache well and ensure our iterations are efficient as the next nodes will be available in the CPU cache, not requiring us to fetch them from the main memory.
Here's the video of my explaining this in-depth ?? do check it out
Thank you so much for reading ?? If you found this helpful, do spread the word about it on social media; it would mean the world to me.
If you liked this short essay, you might also like my courses on
I teach an interactive course on System Design where you'll learn how to intuitively design scalable systems. The course will help you
I have compressed my ~10 years of work experience into this course, and aim to accelerate your engineering growth 100x. To date, the course is trusted by 800+ engineers from 11 different countries and here you can find what they say about the course.
Together, we will dissect and build some amazing systems and understand the intricate details. You can find the week-by-week curriculum and topics, testimonials, and other information at https://arpitbhayani.me/masterclass .
Sr Director Engg @JioCinema | Building at Scale | Cloud native | ex-Atlassian | Thrives in startup mode
2 年Been reading these for a while now and I must say Arpit, you're doing a great job of explaining the internals at this depth. I've also been consuming your YouTube videos and am learning so much about systems and engineering, small and big! ?? More power to you, keep shining! ?
More about me: arpitbhayani.me Newsletter: arpitbhayani.me/newsletter Subscribe #AsliEngineering for such in-depth engineering concepts: https://www.youtube.com/c/ArpitBhayani System Design course: arpitbhayani.me/masterclass Microservices: https://courses.arpitbhayani.me/designing-microservices All GitHub Outages: https://courses.arpitbhayani.me/github-outage-dissections/