puzpuzpuz-hn

Thanks! We do our best to be as transparent as possible when it comes to benchmarking.

Thanks for the reference. Will check!

Exactly! The task gets even trickier when you're benchmarking lots of systems of different kinds: cloud databases, self-hosted ones, embedded engines, CLI tools.

Allocation rates comparison is included. If your application writes into the map most of the time, you should go with plain map + RWMutex (or orcaman/concurrent-map). But if, for instance, you're using the map as a cache, read operations will dominate and having better read scalability becomes important. As an example, Otter cache library uses a modified variant of xsync.Map, not a plain map + RWMutex.

Thanks. There are downsides in each approach, e.g. if you care about minimal allocation rate, you should go with plain map + RWMutex. So yeah, no silver bullet.

Unsafe usage in the recent xsync versions is very limited (runtime.cheaprand only). On the other hand, your point is valid and it'd be great to see standard library improvements.

My box is 12c/24t only, so it won't make any difference. But on a beefy box, it may improve performance in high cardinality key scenarios.

There are multiple GH issues around better sync.Map. Among other alternatives, xsync.Map is also mentioned. But Golang core team doesn't seem interested in sync.Map (or a generic variant of it) improvements.

Would be great to see that - there are multiple GH issues for that. But so far, I'm not convinced that Google prioritizes community requests over its own needs.

Allocation rates are also compared. Long story short, vanilla map + RWMutex (or a sharded variant of it like orcaman/concurrent-map) is the way to go if you want to minimize allocations. On the other hand, if reads dominate your workload, using one of custom concurrent maps may be a good idea.

Yup, that's a valid point. I'll consider adding these metrics.

Benchmarks for 5 concurrent hash map implementations in Go: sync.Map, xsync.Map, cornelk/hashmap, alphadose/haxmap, and orcaman/concurrent-map.

Workloads: read-heavy to write-heavy (100%/99%/90%/75% reads), with and without warm-up, plus range-under-contention (iteration while a writer mutates the map).

Key types: string and int. Map sizes: 100 to 1M entries. GOMAXPROCS: 1, 4, 8, 12.

Results are in the README with plots and a summary table.

Disclaimer: I'm the author of xsync, one of the libraries benchmarked here. I did my best to keep the benchmark fair. If you spot issues or think another library should be included, please open an issue or PR.

Nice article, thanks for sharing it. It's a pity kdb+ has a DeWitt Clause, so that no one can benchmark it against other databases from the article. I wonder if they have any public benchmarks held by a 3rd-party.

Hi, if you're asking about the hash table itself, then currently we use linear probing, i.e. k/v pairs with a collision are inserted sequentially starting with the hash%capacity index.