Crates.io | ccache |
lib.rs | ccache |
version | 0.1.0 |
source | src |
created_at | 2021-05-04 17:17:56.85942 |
updated_at | 2021-05-04 17:17:56.85942 |
description | Composable Caches |
homepage | https://github.com/LucaFulchir/ccache |
repository | https://github.com/LucaFulchir/ccache |
max_upload_size | |
id | 393112 |
size | 105,447 |
Some caches are a combination of multiple others This project tries to create a minimal framework to implement such caches, and provides a common hashmap and traits to reuse and reimplement everything in any way you want.
We also provide an (optional) way to store other metadata along with the values in the cache and have callbacks triggered for every get/insert operation
The basic idea is to implement a w-tlfu cache as per this paper
W-TLFU works by having counters which are all halved every X accesses.
This seems problematic for larger caches, so instead we implemented a lazy scan:
instead of just a counter, each object keeps a generation (Day/Night
) along
with the counter.
Every time an object is accessed we scan it and the next one.
If the generation is not the current one, the counter is halved.
Due to memory alignment SW-TLFU does not implement the "doorkeeper" bloom filter and stores the counters directly in the hashmap used by the caches.
user::Entry
with smaller indexesunsafe
that I hope could be resolved but am not knowledgeable
enough in rustWe had to reimplement an hashmap since the standard ones do not let you access its entries by index, and are not stable (the objects can move around on insert/remove)
The implementation is based on the same RawTable
used by hashbrown
user::Entry
You can reimplement you own entry type, assuming you provide the necessary traits
You can add or better hide some fields, like swtlfu::Full32
does to cram a
Generation and a counter in the cache id
Entries must know in which sub-cache they are, but if you are only using one
cache you can use PhantomData
This is the implementation of a shared cache. By Shared cache we mean one or more probably more caches that reuse the same (shared) hashmap