Personal Perspective on 7 Cache Algorithms

[Yiling-J]

I think supporting over 7 cache algorithms in a caching library might not be advantage. In fact, it often leads to confusion among developers. Instead of providing multiple options, it's usually more effective to implement a single, well-optimized policy, like W-TinyLFU or S3-FIFO, that works well in most scenarios. Actually maybe you can use Moka directly because most code are in Rust part and PyObjects are stored in Rust hashmap directly.

I'm currently rewriting Theine v2 and decide to keep a single policy only, eliminating the need for developers to choose between multiple algorithms.

[awolverp]

This is a good idea, but actually I only focused on speed and performance, I think a policy with multiple options for caching cannot provide the best speed because it have to check a lot of conditions and situations. But now in every policy everything is completely clear.
But if there's a good way to do it, I welcome it.

[Yiling-J]

I would say that hit ratio is also a part of performance, and it's even more important in Python compared to other high-performance languages. In Python, your efforts to increase throughput performance can easily be undermined by just a few lines of naive native code :( . But the high hit ratio always shines. Additionally, due to the high memory overhead of Python objects, you typically can't store many items in the cache, making hit ratio even more crucial.

Honestly, the most popular cachetools isn't a great example. It works, but we can certainly do better by learning from the best cache libraries in other languages, rather than just following it.

[awolverp]

Yeah you're right. At first my goal is only create a fast caching library to use in my projects rather than cachetools (as you said it only works, isnt a good choice). I didn't think about other things.

I saw Moka rust crate but I didn't like its usage structure.