Viewing profile — 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 i…

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 v…

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 alloca…

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…

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 publi…

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 in…

That's correct. In practice, there is an insignificant amount of hash collisions, so false comparisons are extremely rare. And thanks for sharing your experience with RH and the li…

> Unless I'm missing something, hashing function is fast compared to random bouncing around inside ram – very much faster then random memory accesses. So I can't see how it make a …

Thanks, Gavin, I'm pleased to hear that. And thanks for recommending my blog!

Thanks! We're still benchmarking Robin Hood hashing and are open to further experiments. The benchmarks look promising.

> Obviously, it's a bit sad when due credit is not given where it should be The post actually references your paper. :)

Yes, the core idea is pretty close to Epoch-based synchronization.

Recently we've started using io_uring for disk access in QuestDB. So far, it's being used in CSV import, but we'd like to expand it to network and other disk access use cases. Apar…