My point is more to do with the fact that BigCache does not handle collisions at all, whereas the built in Go `map` almost certainly does.
Essentially, I can imagine that a Jepsen-like test would reveal that BigCache loses some percentage of writes (dependent on the data, of course).
Whether or not that is a problem depends entirely on your use case, of course.
Seems like this would always be undesirable behavior for a cache?
It is definitely being advertised as a map-like structure, key goes in, bytes come out...
Update:
Yes, that appears to be the strategy in shard.go.
if entryKey := readKeyFromEntry(wrappedEntry); key != entryKey {
s.lock.RUnlock()
s.collision()
if s.isVerbose {
s.logger.Printf("Collision detected. Both %q and %q have the same hash %x", key, entryKey, hashedKey)
}
return nil, ErrEntryNotFound
}
> BigCache does not handle collisions. When new item is inserted and it's hash collides with previously stored item, new item overwrites previously stored value.
This property makes BigCache what is known as a "Direct-mapped cache"[0]. A direct mapped cache does lead to a worse cache hit rate, but it does make determining whether there is a cache hit or miss a lot faster. I would need to see benchmarks to tell which is better in practice.
[0] https://en.wikipedia.org/wiki/Cache_placement_policies#Direc...