You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Go 1.9 implementation of sync.Map, storing any new key in the map causes Load calls on all new keys to acquire a mutex until enough misses have occurred to promote the read-write map again.
That's probably fine for append-only maps (such as the sync.Map uses in the standard library), because it goes away in the steady state. However, it's problematic for use in caches, where there may be frequent Load and Store calls for keys that miss the cache.
I suspect we could substantially reduce the Load penalty by using a Bloom or HyperLogLog filter instead of a simple boolean to store the set of new keys: a Load that misses in the read-only map would still have more cache misses due to writes to the filter, but it would no longer block Store calls or contend with other Loads.
The text was updated successfully, but these errors were encountered:
In the Go 1.9 implementation of
sync.Map
, storing any new key in the map causesLoad
calls on all new keys to acquire a mutex until enough misses have occurred to promote the read-write map again.That's probably fine for append-only maps (such as the
sync.Map
uses in the standard library), because it goes away in the steady state. However, it's problematic for use in caches, where there may be frequentLoad
andStore
calls for keys that miss the cache.I suspect we could substantially reduce the
Load
penalty by using a Bloom or HyperLogLog filter instead of a simple boolean to store the set of new keys: aLoad
that misses in the read-only map would still have more cache misses due to writes to the filter, but it would no longer blockStore
calls or contend with otherLoad
s.The text was updated successfully, but these errors were encountered: