Hash table

Imagine needing to quickly find a specific piece of information in a vast sea of data—a name in a phone book, a product in an inventory, or a key in a software program. Hash tables are ingenious data structures that make this almost instantaneous, transforming complex searches into simple lookups. They are fundamental to modern computing, powering everything from your web browser's cache to vast database systems, yet their magic lies in a clever trick that helps organize chaos. Hash tables efficiently map unique 'keys' to their corresponding 'values' by using a special function to calculate where data should be stored. A major challenge in hash tables is 'collisions,' where different keys compute the same storage location, requiring clever strategies to resolve them. The performance of a hash table is critically dependent on its 'load factor' and the quality of its 'hash function,' which determine how quickly data can be accessed.

Source: Wikipedia

AI Summary

Imagine needing to quickly find a specific piece of information in a vast sea of data—a name in a phone book, a product in an inventory, or a key in a software program. Hash tables are ingenious data structures that make this almost instantaneous, transforming complex searches into simple lookups. They are fundamental to modern computing, powering everything from your web browser's cache to vast database systems, yet their magic lies in a clever trick that helps organize chaos.

What is a Hash Table?

At its core, a hash table is a data structure that implements an 'associative array'—think of it like a dictionary where you look up a word (the 'key') to find its definition (the 'value'). But unlike a traditional dictionary, which might be sorted alphabetically, a hash table uses a special algorithm to make finding that definition incredibly fast.

The secret sauce is a 'hash function.' This mathematical function takes your key—like a name or a product ID—and transforms it into a numerical index. This index then points directly to a specific 'bucket' or 'slot' in an underlying array where the corresponding value is stored.

So, when you want to find something, you don't search through every item. You just feed the key into the hash function, get an index, and jump straight to that location. It's like having a super-powered index in a book that tells you the exact page number for every single concept, instantly.

The Challenge: Hash Collisions

Life would be simple if every key produced a unique index. But most hash functions are 'imperfect.' This means it's possible—even common—for two different keys to generate the exact same index. This unwelcome event is called a 'hash collision'.

Imagine two different names, 'John Smith' and 'Jane Doe,' both hashing to bucket number 5. You can't store both in the same spot! This is where 'collision resolution' techniques come into play, which are crucial for a hash table to function correctly and efficiently.

Performance Powerhouse

When designed well, hash tables offer incredible speed. On average, the time it takes to find, insert, or delete an item is constant—meaning it doesn't significantly increase even if you have millions of items. This makes them often more efficient than other data structures like search trees for many tasks.

This efficiency is a classic 'space-time tradeoff.' You use a bit more memory (the array of buckets) to gain a huge advantage in time (faster operations). This trade-off is often worth it, making hash tables indispensable in computing.

A Brief History

The concept of hashing emerged independently in several places in the 1950s. IBM researchers like Hans Peter Luhn and Gene Amdahl were early pioneers, implementing hashing for the IBM 701 assembler. Luhn's internal memorandum in 1953 described using hashing with 'chaining'—a collision resolution method we'll explore soon.

The term 'hashing' itself appeared in print a bit later, in an article by Robert Morris. These early innovations laid the groundwork for one of computer science's most enduring and widely used data structures, whose principles are still applied today.

The Load Factor

A critical measure for any hash table is its 'load factor,' often denoted by the Greek letter alpha (α). It tells us how full the table is, which directly impacts its performance. It's simply the number of items currently stored divided by the total number of available buckets.

Here, 'n' is the number of entries in the table, and 'm' is the total number of buckets. As 'α' increases, the chances of collisions go up, and the table's performance can start to degrade. Keeping this value in an optimal range is key to efficiency.

\alpha = \frac{n}{m}

To maintain good performance, software often resizes or 'rehashes' the table if the load factor gets too high—or even too low, to save memory. This involves creating a larger (or smaller) new table and moving all existing items into it, recalculating their hash values for the new size.

Collision Resolution: Separate Chaining

One of the most intuitive ways to handle collisions is 'separate chaining.' Instead of each bucket holding just one item, it holds a pointer to a list—often a linked list—of all the key-value pairs that hash to that same bucket.

When a collision occurs, the new item is simply added to the linked list at that bucket's location. To find an item, you hash its key, go to the bucket, and then traverse the linked list until you find your specific key. This gracefully handles any number of collisions.

The load factor for separate chaining can even exceed 1.0, meaning there are more items than buckets. However, performance gradually declines as lists grow longer. A load factor between 1 and 3 is often considered optimal, balancing memory usage and lookup speed.

Collision Resolution: Open Addressing

Another popular strategy is 'open addressing.' Here, every key-value pair is stored directly within the hash table's array, never in external lists. When a collision occurs, the system 'probes' for an empty slot nearby until one is found.

There are several common probing methods:

Probing Method	Description
Linear Probing	Examines adjacent slots sequentially until an empty one is found.
Quadratic Probing	Increases the interval between probes by squaring the previous step, creating a wider search.
Double Hashing	Uses a secondary hash function to calculate the step size for probing, providing more flexibility.

Open addressing is very sensitive to the load factor. If the table gets too full (approaching a load factor of 1), performance can degrade dramatically as probes become very long. A max load factor of 0.6 to 0.75 is often recommended for good performance.

A key advantage of open addressing, particularly linear probing, is its 'cache-friendliness.' Because items are stored close together in memory, the CPU's cache can retrieve data more efficiently, potentially leading to faster access times.

Crafting the Hash Function

The effectiveness of a hash table hinges on a good hash function. Its primary goal is to distribute keys as uniformly as possible across all the available buckets, minimizing collisions. A non-uniform distribution leads to 'clustering,' where many keys end up in the same few buckets, slowing things down.

One common method for integer keys is 'hashing by division,' which simply uses the remainder of the key divided by the table size. This works best when the table size 'm' is a prime number, as it helps distribute hash values more evenly.

Here, 'x' is the key, and 'm' is the number of buckets in the hash table. The modulo operator (%) gives us the remainder, which becomes our index.

h(x) = x \pmod m

Another technique is 'hashing by multiplication.' This involves multiplying the key by a real-valued constant between 0 and 1, taking the fractional part, and then scaling it by the table size. Donald Knuth, a legendary computer scientist, even suggested using the 'golden ratio' for this constant.

In this formula, 'x' is the key, 'A' is the constant, and 'm' is the table size. The 'mod 1' operation gets the fractional part, which is then scaled and truncated to an integer index. An advantage here is that 'm' doesn't need to be prime.

h(x) = \lfloor m \cdot (xA \pmod 1) \rfloor

Dynamic Resizing

As a hash table grows with more insertions, its load factor increases. To maintain that desirable O(1) average performance, the table often needs to resize. This typically means allocating a completely new, larger array (perhaps double the size) and then 'rehashing' every single existing item into the new table.

Why rehash? Because the hash function often depends on the table size (like with the modulo operator), a new size means new indices for almost all keys. This re-allocation and re-computation can be computationally expensive, but it ensures performance remains high over time.

For systems that can't tolerate a sudden slowdown from a full rehash, there are incremental resizing strategies. Techniques like 'linear hashing' allow the table to grow or shrink one bucket at a time, spreading the cost of resizing over many operations rather than doing it all at once.

Modern Variants

Beyond the basic separate chaining and open addressing, more sophisticated techniques exist. 'Cuckoo hashing,' for example, uses multiple hash functions and tables, moving keys between them like cuckoo birds in a nest, guaranteeing constant worst-case lookup time.

'Robin Hood hashing' is another clever open addressing variant that prioritizes displacing items that are far from their 'home' bucket, leading to a more even distribution of probe sequence lengths and reducing performance variance. These advanced methods push the boundaries of what hash tables can achieve.

From database indexing to caching and beyond, hash tables are an unsung hero of computer science, providing the underlying speed that makes so much of our digital world operate seamlessly. Their elegant blend of simplicity and efficiency continues to make them a cornerstone of modern software.

Article

Hash table

A small phone book as a hash table

In computer science, a hash table is a data structure that implements an associative array, also called a dictionary or simply map; an associative array is an abstract data type that maps keys to values. A hash table uses a hash function to compute an index, also called a hash code, into an array of buckets or slots, from which the desired value can be found. During lookup, the key is hashed and the resulting hash indicates where the corresponding value is stored. A map implemented by a hash table is called a hash map.

Most hash table designs employ an imperfect hash function. Hash collisions, where the hash function generates the same index for more than one key, therefore typically must be accommodated in some way. Common strategies to handle hash collisions include chaining, which stores multiple elements in the same slot using linked lists, and open addressing, which searches for the next available slot according to a probing sequence.

In a well-dimensioned hash table, the average time complexity for each lookup is independent of the number of elements stored in the table. Many hash table designs also allow arbitrary insertions and deletions of key–value pairs, at amortized constant average cost per operation.

Hashing is an example of a space–time tradeoff. If memory is infinite, the entire key can be used directly as an index to locate its value with a single memory access. On the other hand, if infinite time is available, values can be stored without regard for their keys, and a binary search or linear search can be used to retrieve the element.

In many situations, hash tables turn out to be on average more efficient than search trees or any other table lookup structure. For this reason, they are widely used in many kinds of computer software, particularly for associative arrays, database indexing, caches, and sets. Many programming languages provide built-in hash table structures, such as Python’s dictionaries, Java’s HashMap, C++’s unorderedmap, Go maps, which abstract the complexity of hashing from the programmer.

History

Hash table

The idea of hashing arose independently in different places. In January 1953, Hans Peter Luhn wrote an internal IBM memorandum that used hashing with chaining. The first example of open addressing was proposed by A. D. Linh, building on Luhn's memorandum. Around the same time, Gene Amdahl, Elaine M. McGraw, Nathaniel Rochester, and Arthur Samuel of IBM Research implemented hashing for the IBM 701 assembler. Open addressing with linear probing is credited to Amdahl, although Andrey Ershov independently had the same idea. The term "open addressing" was coined by W. Wesley Peterson in his article which discusses the problem of search in large files.

The first published work on hashing with chaining is credited to Arnold Dumey, who discussed the idea of using remainder modulo a prime as a hash function. The word "hashing" was first published in an article by Robert Morris. A theoretical analysis of linear probing was submitted originally by Konheim and Weiss.

Overview

Hash table

An associative array stores a set of (key, value) pairs and allows insertion, deletion, and lookup (search), with the constraint of unique keys. In the hash table implementation of associative arrays, an array ${\displaystyle A}$ of length ${\displaystyle m}$ is partially filled with ${\displaystyle n}$ elements, where ${\displaystyle m\geq n}$. A key ${\displaystyle x}$ is hashed using a hash function ${\displaystyle h}$ to compute an index location ${\displaystyle A[h(x)]}$ in the hash table, where ${\displaystyle h(x)<m}$. The efficiency of a hash table depends on the load factor, defined as the ratio of the number of stored elements to the number of available slots, with lower load factors generally yielding faster operations. At this index, both the key and its associated value are stored. Storing the key alongside the value ensures that lookups can verify the key at the index to retrieve the correct value, even in the presence of collisions. Under reasonable assumptions, hash tables have better time complexity bounds on search, delete, and insert operations in comparison to self-balancing binary search trees.

Hash tables are also commonly used to implement sets, by omitting the stored value for each key and merely tracking whether the key is present.

Load factor

A load factor ${\displaystyle \alpha }$ is a critical statistic of a hash table, and is defined as follows: ${\displaystyle {\text{load factor}}\ (\alpha )={\frac {n}{m}},}$ where

• ${\displaystyle n}$ is the number of entries occupied in the hash table. • ${\displaystyle m}$ is the number of buckets.

The performance of the hash table deteriorates in relation to the load factor ${\displaystyle \alpha }$. In the limit of large ${\displaystyle m}$ and ${\displaystyle n}$, each bucket statistically has a Poisson distribution with expectation ${\displaystyle \lambda =\alpha }$ for an ideally random hash function.

The software typically ensures that the load factor ${\displaystyle \alpha }$ remains below a certain constant, ${\displaystyle \alpha {\max }}$. This helps maintain good performance. Therefore, a common approach is to resize or "rehash" the hash table whenever the load factor ${\displaystyle \alpha }$ reaches ${\displaystyle \alpha {\max }}$. Similarly the table may also be resized if the load factor drops below ${\displaystyle \alpha {\max }/4}$.

Load factor for separate chaining

With separate chaining hash tables, each slot of the bucket array stores a pointer to a list or array of data.

Separate chaining hash tables suffer gradually declining performance as the load factor grows, and no fixed point beyond which resizing is absolutely needed.

With separate chaining, the value of ${\displaystyle \alpha {\max }}$ that gives best performance is typically between 1 and 3.

Load factor for open addressing

With open addressing, each slot of the bucket array holds exactly one item. Therefore an open-addressed hash table cannot have a load factor greater than 1.

The performance of open addressing becomes very bad when the load factor approaches 1.

Therefore a hash table that uses open addressing must be resized or rehashed if the load factor ${\displaystyle \alpha }$ approaches 1.

With open addressing, acceptable figures of max load factor ${\displaystyle \alpha {\max }}$ should range around 0.6 to 0.75.

Hash function

Hash table

A hash function ${\displaystyle h:U\rightarrow \{0,...,m-1\}}$ maps the universe ${\displaystyle U}$ of keys to indices or slots within the table, that is, ${\displaystyle h(x)\in \{0,...,m-1\}}$ for ${\displaystyle x\in U}$. The conventional implementations of hash functions are based on the integer universe assumption that all elements of the table stem from the universe ${\displaystyle U=\{0,...,u-1\}}$, where the bit length of ${\displaystyle u}$ is confined within the word size of a computer architecture.

A hash function ${\displaystyle h}$ is said to be perfect for a given set ${\displaystyle S}$ if it is injective on ${\displaystyle S}$, that is, if each element ${\displaystyle x\in S}$ maps to a different value in ${\displaystyle {0,...,m-1}}$. A perfect hash function can be created if all the keys are known ahead of time.

Integer universe assumption

The schemes of hashing used in integer universe assumption include hashing by division, hashing by multiplication, universal hashing, dynamic perfect hashing, and static perfect hashing. However, hashing by division is the commonly used scheme.

Hashing by division

The scheme in hashing by division is as follows: ${\displaystyle h(x)\ =\ x\,{\bmod {\,}}m,}$ where ${\displaystyle h(x)}$ is the hash value of ${\displaystyle x\in S}$ and ${\displaystyle m}$ is the size of the table.

Hashing by multiplication

The scheme in hashing by multiplication is as follows: ${\displaystyle h(x)=\lfloor m{\bigl (}(xA){\bmod {1}}{\bigr )}\rfloor }$ Where ${\displaystyle A}$ is a non-integer real-valued constant and ${\displaystyle m}$ is the size of the table. An advantage of the hashing by multiplication is that the ${\displaystyle m}$ is not critical. Although any value ${\displaystyle A}$ produces a hash function, Donald Knuth suggests using the golden ratio.

String hashing

Commonly a string is used as a key to the hash function. The third edition of The C++ Programming Language describes a simple hash function in which an unsigned integer that is initially zero is repeatedly left shifted one bit and then xor'ed with the integer value of the next character. This hash value is then taken modulo the table size. If the left shift is not circular, then the string length should be at least eight bits less than the size of the unsigned integer in bits. Another common way to hash a string to an integer is with a polynomial rolling hash function.

Choosing a hash function

Uniform distribution of the hash values is a fundamental requirement of a hash function. A non-uniform distribution increases the number of collisions and the cost of resolving them. Uniformity is sometimes difficult to ensure by design, but may be evaluated empirically using statistical tests, e.g., a Pearson's chi-squared test for discrete uniform distributions.

The distribution needs to be uniform only for table sizes that occur in the application. In particular, if one uses dynamic resizing with exact doubling and halving of the table size, then the hash function needs to be uniform only when the size is a power of two. Here the index can be computed as some range of bits of the hash function. On the other hand, some hashing algorithms prefer to have the size be a prime number.

For open addressing schemes, the hash function should also avoid runs, the mapping of two or more keys to consecutive slots. Such runs may cause the lookup cost to skyrocket, even if the load factor is low and collisions are infrequent. The popular multiplicative hash is claimed to have particularly poor run behavior.

K-independent hashing offers a way to prove a certain hash function does not have bad keysets for a given type of hashtable. A number of K-independence results are known for collision resolution schemes such as linear probing and cuckoo hashing. Since K-independence can prove a hash function works, one can then focus on finding the fastest possible such hash function.

Collision resolution

Hash table

A search algorithm that uses hashing consists of two parts. The first part is computing a hash function which transforms the search key into an array index. The ideal case is such that no two search keys hash to the same array index. However, this is not always the case and impossible to guarantee for unseen given data. Hence the second part of the algorithm is collision resolution. The two common methods for collision resolution are separate chaining and open addressing.

Separate chaining

Hash collision resolved by separate chaining

Hash collision by separate chaining with head records in the bucket array

In separate chaining, the process involves building a linked list with key–value pair for each search array index. The collided items are chained together through a single linked list, which can be traversed to access the item with a unique search key. Collision resolution through chaining with linked list is a common method of implementation of hash tables. Let ${\displaystyle T}$ and ${\displaystyle x}$ be the hash table and the node respectively, the operation involves as follows:

If the element is comparable either numerically or lexically, and inserted into the list by maintaining the total order, it results in faster termination of the unsuccessful searches.

Other data structures for separate chaining

If the keys are ordered, it could be efficient to use "self-organizing" concepts such as using a self-balancing binary search tree, through which the theoretical worst case could be brought down to ${\displaystyle O(\log {n})}$, although it introduces additional complexities.

In dynamic perfect hashing, two-level hash tables are used to reduce the look-up complexity to be a guaranteed ${\displaystyle O(1)}$ in the worst case. In this technique, the buckets of ${\displaystyle k}$ entries are organized as perfect hash tables with ${\displaystyle k^{2}}$ slots providing constant worst-case lookup time, and low amortized time for insertion. A study shows array-based separate chaining to be 97% more performant when compared to the standard linked list method under heavy load.

Techniques such as using fusion tree for each buckets also result in constant time for all operations with high probability.

Caching and locality of reference

The linked list of separate chaining implementation may not be cache-conscious due to spatial locality—locality of reference—when the nodes of the linked list are scattered across memory, thus the list traversal during insert and search may entail CPU cache inefficiencies.

In cache-conscious variants of collision resolution through separate chaining, a dynamic array found to be more cache-friendly is used in the place where a linked list or self-balancing binary search trees is usually deployed, since the contiguous allocation pattern of the array could be exploited by hardware-cache prefetchers—such as translation lookaside buffer—resulting in reduced access time and memory consumption.

Open addressing

Hash collision resolved by open addressing with linear probing (interval=1). Note that "Ted Baker" has a unique hash, but nevertheless collided with "Sandra Dee", that had previously collided with "John Smith".

Open addressing is another collision resolution technique in which every entry record is stored in the bucket array itself, and the hash resolution is performed through probing. When a new entry has to be inserted, the buckets are examined, starting with the hashed-to slot and proceeding in some probe sequence, until an unoccupied slot is found. When searching for an entry, the buckets are scanned in the same sequence, until either the target record is found, or an unused array slot is found, which indicates an unsuccessful search.

• Linear probing, in which the interval between probes is fixed (usually 1). • Quadratic probing, in which the interval between probes is increased by adding the successive outputs of a quadratic polynomial to the value given by the original hash computation. • Double hashing, in which the interval between probes is computed by a secondary hash function.

The performance of open addressing may be slower compared to separate chaining since the probe sequence increases when the load factor ${\displaystyle \alpha }$ approaches 1. The probing results in an infinite loop if the load factor reaches 1, in the case of a completely filled table. The average cost of linear probing depends on the hash function's ability to distribute the elements uniformly throughout the table to avoid runs, since formation of runs would result in increased search time.

Caching and locality of reference

Since the slots are located in successive locations, linear probing could lead to better utilization of CPU cache due to locality of references resulting in reduced memory latency.

Coalesced hashing

Coalesced hashing is a hybrid of both separate chaining and open addressing in which the buckets or nodes link within the table. The algorithm is ideally suited for fixed memory allocation. The collision in coalesced hashing is resolved by identifying the largest-indexed empty slot on the hash table, then the colliding value is inserted into that slot. The bucket is also linked to the inserted node's slot which contains its colliding hash address.

Cuckoo hashing

Cuckoo hashing is a form of open addressing collision resolution technique which guarantees ${\displaystyle O(1)}$ worst-case lookup complexity and constant amortized time for insertions. The collision is resolved through maintaining two hash tables, each having its own hashing function, and collided slot gets replaced with the given item, and the preoccupied element of the slot gets displaced into the other hash table. The process continues until every key has its own spot in the empty buckets of the tables; if the procedure enters into infinite loop—which is identified through maintaining a threshold loop counter—both hash tables get rehashed with newer hash functions and the procedure continues.

Hopscotch hashing

Hopscotch hashing is an open addressing based algorithm which combines the elements of cuckoo hashing, linear probing and chaining through the notion of a neighbourhood of buckets—the subsequent buckets around any given occupied bucket, also called a "virtual" bucket. The algorithm is designed to deliver better performance when the load factor of the hash table grows beyond 90%; it also provides high throughput in concurrent settings, thus well suited for implementing resizable concurrent hash table. The neighbourhood characteristic of hopscotch hashing guarantees a property that, the cost of finding the desired item from any given buckets within the neighbourhood is very close to the cost of finding it in the bucket itself; the algorithm attempts to be an item into its neighbourhood—with a possible cost involved in displacing other items.

Each bucket within the hash table includes an additional "hop-information"—an H-bit bit array for indicating the relative distance of the item which was originally hashed into the current virtual bucket within H − 1 entries. Let ${\displaystyle k}$ and ${\displaystyle Bk}$ be the key to be inserted and bucket to which the key is hashed into respectively; several cases are involved in the insertion procedure such that the neighbourhood property of the algorithm is vowed: if ${\displaystyle Bk}$ is empty, the element is inserted, and the leftmost bit of bitmap is set to 1; if not empty, linear probing is used for finding an empty slot in the table, the bitmap of the bucket gets updated followed by the insertion; if the empty slot is not within the range of the neighbourhood, i.e. H − 1, subsequent swap and hop-info bit array manipulation of each bucket is performed in accordance with its neighbourhood invariant properties.

Robin Hood hashing

Robin Hood hashing is an open addressing based collision resolution algorithm; the collisions are resolved through favouring the displacement of the element that is farthest—or longest probe sequence length (PSL)—from its "home location" i.e. the bucket to which the item was hashed into. It is named after Robin Hood, a mythical heroic outlaw who stole from the rich to give to the poor.

Although Robin Hood hashing does not change the theoretical search cost, it significantly affects the variance of the distribution of the items on the buckets, i.e. dealing with long run formation in the hash table. Each node within the hash table that uses Robin Hood hashing should be augmented to store an extra PSL value. Let ${\displaystyle x}$ be the key to be inserted, ${\displaystyle x{.}{\text{psl}}}$ be the (incremental) PSL length of ${\displaystyle x}$, ${\displaystyle T}$ be the hash table and ${\displaystyle j}$ be the index, the insertion procedure is as follows:

• If ${\displaystyle x{.}{\text{psl}}\ \leq \ T[j]{.}{\text{psl}}}$: the iteration goes into the next bucket without attempting an external probe. • If ${\displaystyle x{.}{\text{psl}}\ >\ T[j]{.}{\text{psl}}}$: insert the item ${\displaystyle x}$ into the bucket ${\displaystyle j}$; swap ${\displaystyle x}$ with ${\displaystyle T[j]}$—let it be ${\displaystyle x'}$; continue the probe from the ${\displaystyle (j+1)}$th bucket to insert ${\displaystyle x'}$; repeat the procedure until every element is inserted.

Dynamic resizing

Hash table

Repeated insertions cause the number of entries in a hash table to grow, which consequently increases the load factor; to maintain the amortized ${\displaystyle O(1)}$ performance of the lookup and insertion operations, a hash table is dynamically resized and the items of the tables are rehashed into the buckets of the new hash table, since the items cannot be copied over as varying table sizes results in different hash value due to modulo operation. If a hash table becomes "too empty" after deleting some elements, resizing may be performed to avoid excessive memory usage.

Resizing by moving all entries

Generally, a new hash table with a size double that of the original hash table gets allocated privately and every item in the original hash table gets moved to the newly allocated one by computing the hash values of the items followed by the insertion operation. Rehashing is simple, but computationally expensive.

Alternatives to all-at-once rehashing

Some hash table implementations, notably in real-time systems, cannot pay the price of enlarging the hash table all at once, because it may interrupt time-critical operations. If one cannot avoid dynamic resizing, a solution is to perform the resizing gradually to avoid storage blip—typically at 50% of new table's size—during rehashing and to avoid memory fragmentation that triggers heap compaction due to deallocation of large memory blocks caused by the old hash table. In such case, the rehashing operation is done incrementally through extending prior memory block allocated for the old hash table such that the buckets of the hash table remain unaltered. A common approach for amortized rehashing involves maintaining two hash functions ${\displaystyle h{\text{old}}}$ and ${\displaystyle h{\text{new}}}$. The process of rehashing a bucket's items in accordance with the new hash function is termed as cleaning, which is implemented through command pattern by encapsulating the operations such as ${\displaystyle \mathrm {Add} (\mathrm {key} )}$, ${\displaystyle \mathrm {Get} (\mathrm {key} )}$ and ${\displaystyle \mathrm {Delete} (\mathrm {key} )}$ through a ${\displaystyle \mathrm {Lookup} (\mathrm {key} ,{\text{command}})}$ wrapper such that each element in the bucket gets rehashed and its procedure involve as follows:

• Clean ${\displaystyle \mathrm {Table} [h{\text{old}}(\mathrm {key} )]}$ bucket. • Clean ${\displaystyle \mathrm {Table} [h{\text{new}}(\mathrm {key} )]}$ bucket. • The command gets executed.

Linear hashing

Linear hashing is an implementation of the hash table which enables dynamic growths or shrinks of the table one bucket at a time.

Performance

Hash table

The performance of a hash table is dependent on the hash function's ability in generating quasi-random numbers (${\displaystyle \sigma }$) for entries in the hash table where ${\displaystyle K}$, ${\displaystyle n}$ and ${\displaystyle h(x)}$ denotes the key, number of buckets and the hash function such that ${\displaystyle \sigma \ =\ h(K)\ \%\ n}$. If the hash function generates the same ${\displaystyle \sigma }$ for distinct keys (${\displaystyle K{1}\neq K{2},\ h(K{1})\ =\ h(K{2})}$), this results in collision, which is dealt with in a variety of ways. The constant time complexity (${\displaystyle O(1)}$) of the operation in a hash table is presupposed on the condition that the hash function doesn't generate colliding indices; thus, the performance of the hash table is directly proportional to the chosen hash function's ability to disperse the indices. However, construction of such a hash function is practically infeasible, that being so, implementations depend on case-specific collision resolution techniques in achieving higher performance.

The best performance is obtained in the case that the hash function distributes the elements of the universe uniformaly, and the elements stored at the table are drawn at random from the universe. In this case, in hashing with chaining, the expected time for a successful search is ${\textstyle 1+{\frac {\alpha }{2}}+\Theta \left({\frac {1}{m}}\right)}$, and the expected time for an unsuccessful search is ${\textstyle e^{-\alpha }+\alpha +\Theta \left({\frac {1}{m}}\right)}$.

Applications

Associative arrays

Hash tables are commonly used to implement many types of in-memory tables. They are used to implement associative arrays.

Database indexing

Hash tables may also be used as disk-based data structures and database indices (such as in dbm) although B-trees are more popular in these applications.

Caches

Hash tables can be used to implement caches, auxiliary data tables that are used to speed up the access to data that is primarily stored in slower media. In this application, hash collisions can be handled by discarding one of the two colliding entries—usually erasing the old item that is currently stored in the table and overwriting it with the new item, so every item in the table has a unique hash value.

Sets

Hash tables can be used in the implementation of set data structure, which can store unique values without any particular order; set is typically used in testing the membership of a value in the collection, rather than element retrieval.

Transposition table

A transposition table to a complex Hash Table which stores information about each section that has been searched.

Implementations

Hash table

Many programming languages provide hash table functionality, either as built-in associative arrays or as standard library modules.

• In JavaScript, an "object" is a mutable collection of key–value pairs (called "properties"), where each key is either a string or a guaranteed-unique "symbol"; any other value, when used as a key, is first coerced to a string. Aside from the seven "primitive" data types, every value in JavaScript is an object. ECMAScript 2015 also added the Map data structure, which accepts arbitrary values as keys. • C++11 includes unorderedmap in its standard library for storing keys and values of arbitrary types. • Go's built-in map implements a map type in the form of a type, which is often (but not guaranteed to be) a hash table. • Java programming language includes the HashSet, HashMap, LinkedHashSet, and LinkedHashMap generic collections. • Python's built-in dict implements a hash table in the form of a type. • Ruby's built-in Hash uses the open addressing model from Ruby 2.4 onwards. • Rust programming language includes HashMap, HashSet as part of the Rust Standard Library. • The .NET standard library includes HashSet and Dictionary, so it can be used from languages such as C# and VB.NET.