Jon Gjengset

@jhinch that could work, though the tricky part is going to be to find the right way to free them. If we can figure that out though, that would probably...

That's a good observation, and yes, I think that could work! That should give a very nice speedup for resizes indeed. Anyone want to write up a PR?

Thinking some more about this, I think the trick will be to allocate a `Moved` for a table _when its replacement is allocated_, and then to store a pointer to...

@domenicquirl Ah, but notice that the drop code uses `epoch::unprotected`, which destroys _immediately_.

Ah, no, what I was thinking about was making sure that all the pointers that point to the shared `BinEntry::Moved` have been dropped before you drop it. The approach you've...

Updated flamegraphs: `flurry_hashbrown insert_flurry_hashbrown/low_guard_once` [](https://jon.tsp.io/share/flurry-hashbrown-insert-low-guard-once-7e60e0d7d2936d71ff19620c571b5efd22202a10.svg) `flurry_dashmap insert_flurry_u64_u64_guard_once/1` [](https://jon.tsp.io/share/flurry-dashmap-insert-u64-guard-once-7e60e0d7d2936d71ff19620c571b5efd22202a10.svg)

I wonder how different these numbers would look with jemalloc... We're certainly being bitten by the cost of allocation here, which `dashmap` and `hashbrown` do not have to pay. I'd...

It is particularly bad that we have to do _two_ allocations for every put -- one for the value and one for the node. We could at least to a...

Thinking some more about this, I don't think a graveyard will help us much. Unless the user does a lot of removals or replacements (which I don't think are _that_...

I wrote a first draft of a more "serious" concurrent benchmark: https://github.com/jonhoo/bustle