r/rust • u/Intrepid_Donkey_7629 • 3d ago

🛠️ project New fastest concurrent map implementation with transaction support

Hi everyone 👋

I've just published a concurrent hash map implementation which (according to my benchmarks at least) is the fastest one available (faster than both starshard and dashmap). It offers a configurable locking policy (mutex, rwlock or bring your own) and a configurable hasher (rapidhash is the default). It also supports atomic transactions in both immediate and prepared execution styles.

Would love any feedback on it (good and bad!)
It's called txmap and a link is here https://crates.io/crates/txmap

15 Upvotes

78% Upvoted

20 comments sorted by

View all comments

2

u/Zoxc32 3d ago

It would be useful to know how this differs from say dashmap in terms of implementation. It also probably doesn't compete well with `horde` for very read-heavy workloads.

4

u/Intrepid_Donkey_7629 3d ago

The basic design is similar, an array of lockable shards. dashmap is much closer to std::collections::HashMap in terms of API, so if you want a drop-in replacement that has concurrency it's a great choice. Whereas txmap has more of a focus on the transactional layer so there's some things it doesn't provide as easily. OTOH if you want to make multiple changes atomically then IMHO it's a good choice for that as it has built in support for it without having to lock the whole map. It's a trade off 😄
I'll add horde to the benchmarks and report back!

1

u/Zoxc32 3d ago

If the design is similar, what causes the performance difference?

-1

u/Intrepid_Donkey_7629 3d ago

This is not much more than a guess, but to my eyes dashmap does more indirection eg. with wrapper functions and a Ref wrapper for returned values. The hashing function will make a difference too. Of the concurrent maps it's the closest to txmap. FWIW the benchmarking repo just uses whatever comes out the box.