> So the rationale is to ensure that only add operations perform a resize > and so that sequential pop() operations don't incur excessive resizing > costs. I agree that the use case of repeated .pop() operations is reasonable, and (IIUC) that case is also special-cased using a finger/index. I think for regular removal, the same logic should not apply: if a series of removals is performed, then further (non-pop) removals see increasing costs, as do regular lookups. So I think that a removal should trigger shrinking (with appropriate thresholds) unless it's a .pop. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4