26 ms·

> SIEVE is nailing it, outperforming the rest in almost all scenarios. I'm curious why there's a lack of transparency regarding the scenarios where SIEVE did n

> SIEVE is nailing it, outperforming the rest in almost all scenarios. 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.

brightball 3y ago
I've always wondered about setting up a Cost-Benefit Cache. Elixir's built in cache made me think of it first because it would simplify the implementation, but it could really be done in any language. 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.
shaicoleman 3y ago
The con is mentioned in the "SIEVE is not scan-resistant" section https://cachemon.github.io/SIEVE-website/blog/2023/12/17/sieve-is-simpler-than-lru/#sieve-is-not-scan-resistant https://cachemon.github.io/SIEVE-website/blog/2023/12/17/sie...

brightball 3y ago

I've always wondered about setting up a Cost-Benefit Cache. Elixir's built in cache made me think of it first because it would simplify the implementation, but it could really be done in any language. 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.

shaicoleman 3y ago

The con is mentioned in the "SIEVE is not scan-resistant" section https://cachemon.github.io/SIEVE-website/blog/2023/12/17/sieve-is-simpler-than-lru/#sieve-is-not-scan-resistant https://cachemon.github.io/SIEVE-website/blog/2023/12/17/sie...