I'm curious why there's a lack of transparency regarding the scenarios where SIEVE did not surpass other algorithms.
Another concern is the emphasis on average performance and P10/P90 metrics. When evaluating a caching algorithm metrics like P99x are often more insightful.
The omission of these details coupled with the sensationalist tone of the article definitely triggers some red flags for me.
https://cachemon.github.io/SIEVE-website/blog/2023/12/17/sie...
The idea being that you track a few stats for each cache item:
a. Time to retrieve the cached data from original source
b. Frequency of requests for the data from the cache
c. Size of the data to be stored
Size of the data to be stored is the "cost" since it takes up space in the cache that could be occupied by other data.
Retrieval time and frequency of requests would be the benefit since it should reflect the amount of time saved (a 5 second query called 4 times / minute would save 20 seconds per minute of execution time).
(a * b) / c = Priority.
Lowest priority gets evicted first as cache size reaches it's limit.
The idea behind doing this is that you could run just about any data that could potentially be cached through the system and it would only be stored if the priority was higher than the lowest priority item currently in the cache. This should also deal with spikes or sudden slowness automatically if a part of the application is suddenly hammered.