3 ms·
In practical applications, costs are often not amortized. If lucky transactions are more than fast enough but unlucky transactions time out because they perfor
by HelloNurse 7y ago
In practical applications, costs are often not amortized.
If lucky transactions are more than fast enough but unlucky transactions time out because they perform a rebuild it's a defect that cannot be accepted because average performance is good.
Most databases need to take care of worst case performance with techniques that increase complexity and degrade best-case and aggregate performance (e.g. maintaining two hash tables, with lookup accessing both, insertions into the preferred one, and background threads that move records from the old table to the new table).
- loeg 7y agoI may have misspoken and should have left out "amortized," perhaps. It doesn't sound like you're familiar with incremental resizing or other real-time techniques?[1] > 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. [1]: https://en.wikipedia.org/wiki/Hash_table#Alternatives_to_all-at-once_rehashing https://en.wikipedia.org/wiki/Hash_table#Alternatives_to_all...