search

swoop-inc / fast_cache

Very fast in-process cache with least-recently used (LRU) and time-to-live (TTL) expiration semantics.
MIT License
11 stars 5 forks source link

Add ActiveSupport interface? #2

Open findchris opened 10 years ago

findchris commented 10 years ago

Nice work with this project. I came to it after looking into why something as ostensibly simple as ActiveSupport::Cache::MemoryStore is slower than I expected, and figuring someone had written something better (and you have!). So thanks for that.

The MemoryStore is a ActiveSupport::Cache::Store, the primary benefit of which is a cache backend-agnostic interface. Would you be interested in making fast_cache inherit from ActiveSupport::Cache::Store, so that it can seamlessly replace MemoryStore? I understand if you want to keep this implementation ActiveSupport-free, but maybe a new project such as fast_cache_store?

Would like to hear your thoughts.

ssimeonov commented 10 years ago

Have you taken a close look at the API ActiveSupport::Cache::Store and its expectations, especially around size-based constraints?

findchris commented 10 years ago

What sized-based constraints?

ssimeonov commented 10 years ago

For example, the handling of a universal option such as :compress_threshold. See http://api.rubyonrails.org/classes/ActiveSupport/Cache.html

findchris commented 10 years ago

So are you saying you're against the idea of a fast_cache-backed Store because of the overhead/bloat of the base class?

ssimeonov commented 10 years ago

Not at all.

I'm saying that some interesting choices have to be made with respect to how to satisfy the so-called "universal" requirements for all stores in a manner that doesn't throw away the performance benefits of fast_cache. I did not have a strong gut sense on this (or a need for it), which is the only reason why I did not create a separate project as you suggest.

If you want to go ahead and do this, I'd be happy to do a code review.