Benchmarks for concurrent hash map implementations in Go github.com 64 points by platzhirsch a day ago
withinboredom 11 minutes ago Looks good! There's an important thing missing from the benchmarks though:- cpu usage under concurrency: many of these spin-lock or use atomics, which can use up to 100% cpu time just spinning.- latency under concurrency: atomics cause cache-line bouncing which kills latency, especially p99 latency
vanderZwan an hour ago I don't write Go but respect to the author for trying to list trade-off considerations for each of the implementations tested, and not just proclaim their library the overal winner.
eatonphil 44 minutes ago Will we also eventually get a generic sync.Map? jeffbee 8 minutes ago Almost certainly, since the internal HashTrieMap is already generic. But for now this author's package stands in nicely.
jeffbee 8 minutes ago Almost certainly, since the internal HashTrieMap is already generic. But for now this author's package stands in nicely.
Looks good! There's an important thing missing from the benchmarks though:
- cpu usage under concurrency: many of these spin-lock or use atomics, which can use up to 100% cpu time just spinning.
- latency under concurrency: atomics cause cache-line bouncing which kills latency, especially p99 latency
I don't write Go but respect to the author for trying to list trade-off considerations for each of the implementations tested, and not just proclaim their library the overal winner.
Will we also eventually get a generic sync.Map?
Almost certainly, since the internal HashTrieMap is already generic. But for now this author's package stands in nicely.