arun1729 / cog

Micro Graph Database for Python Applications
http://cogdb.io
MIT License
294 stars 22 forks source link

load factor for hash table #2

Closed arun1729 closed 3 years ago

arun1729 commented 6 years ago

Alternatives to all-at-once rehashing[edit] 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: Disk-based hash tables almost always use some alternative to all-at-once rehashing, since the cost of rebuilding the entire table on disk would be too high. Incremental resizing[edit] One alternative to enlarging the table all at once is to perform the rehashing gradually: During the resize, allocate the new hash table, but keep the old table unchanged. In each lookup or delete operation, check both tables. Perform insertion operations only in the new table. At each insertion also move r elements from the old table to the new table. When all elements are removed from the old table, deallocate it. To ensure that the old table is completely copied over before the new table itself needs to be enlarged, it is necessary to increase the size of the table by a factor of at least (r + 1)/r during resizing.