bigcache
bigcache copied to clipboard
allegro
FeatureRequest: provide PinnedSlice or something to avoid memmove
For now, every time we get an entry from bigcache when cache hit, bigcache will allocate a new byte slice and copy cache content into it internally. I propose to provide a way to let users to manage the lifetime of the entry they got, to avoid internal memory copy.
type PinnedSlice struct {...}
func (this PinnedSlice) Copy() PinnedSlice {...}
func (this PinnedSlice) Release() {...}
func (c *BigCache) GetPinnedSlice(key string) (PinnedSlice, error)
Internally, we can add a reference count in the header of wrapped entry, just like timestamps. Once we want to evict an entry, we need to check whether its reference count is zero, if not, we should jump across it and check next entry.
@cristaloleg It's related but not totally equal. If this proposal is implemented, we don't need #229 anymore.
@mxplusb Eviction will be a little bit complex. As I mentioned in the description, when we want to evict an entry, we need to check the reference count first. So we need to find a continuous memory long enough to fit in the new entry and all reference counts of old entries in this continuous memory need to be zero. Compare to the size of the whole cache, we can assume most of the cached entries will have zero reference count, so the eviction procedure should not be too expansive.
I can review a PR if you'd like. I don't inherently see a problem with the API, but I would defer to @cristaloleg for whether or they'd want to move forward with it.
If implemented evictions rather than being a single pop operation could potentially take n hops - to find next node to evict. Today queue head always points to the latest node - this I guess would not be true any longer?
I think this might be a good candidate for v3, but I would want to see a reference implementation before saying yea or nay. I think the value of a PinnedSlice or something equivalent could be interesting, but I think it should also be clearly explained on when to use it vs when to not.
// ref: #238