Struct TinyUfo

pub struct TinyUfo<K, T> { /* private fields */ }

TinyUfo cache

Implementations

impl<K: Hash, T: Clone + Send + Sync + 'static> TinyUfo<K, T>

pub fn new(total_weight_limit: usize, estimated_size: usize) -> Self

Create a new TinyUfo cache with the given weight limit and the given size limit of the ghost queue.

pub fn new_compact(total_weight_limit: usize, estimated_size: usize) -> Self

Create a new TinyUfo cache but with more memory efficient data structures. The trade-off is that the the get() is slower by a constant factor. The cache hit ratio could be higher as this type of TinyUFO allows to store more assets with the same memory.

pub fn get(&self, key: &K) -> Option<T>

Read the given key

Return Some(T) if the key exists

pub fn put(&self, key: K, data: T, weight: u16) -> Vec<KV<T>>

Put the key value to the TinyUfo

Return a list of KV of key and T that are evicted

pub fn remove(&self, key: &K) -> Option<T>

Remove the given key from the cache if it exists

Returns Some(T) if the key was found and removed, None otherwise

pub fn force_put(&self, key: K, data: T, weight: u16) -> Vec<KV<T>>

Always put the key value to the TinyUfo

Return a list of KV of key and T that are evicted

Similar to Self::put but guarantee the assertion of the asset. In Self::put, the TinyLFU check may reject putting the current asset if it is less popular than the once being evicted.

In some real world use cases, a few reads to the same asset may be pending for the put action to be finished so that they can read the asset from cache. Neither the above behaviors are ideal for this use case.

Compared to Self::put, the hit ratio when using this function is reduced by about 0.5pp or less in under zipf workloads.