Merb's radical (but very cool) new caching mechanism

merbunity.com

20 points·pius··5 comments

This is maybe a pretty half-baked idea, but could a language that supports partial evaluation replace a pretty significant chunk of most web app caching systems?

I guess the tricky part is that side effects (e.g. another process modifying the database) are pretty much unavoidable with current architecture.

Not really. Caching is (in my understanding) mainly about reducing (disk) I/O, which is very slow. This is a database/persistence problem more than a programming languague problem. Partial/lazy evaluation prevents looking up things you don't need, but doesn't solve the problem of getting what you need as fast as possible.

Caching is also very much not limited in usefulness to I/O-bound operations; a cache hit can save a great deal of CPU time, too, if you have difficult-to-compute values that are sufficiently static to be worth caching.

Even if your whole dataset fits into RAM, you may still have that one O(2^N) algorithm that doesn't need to be run for every request. Voila! A perfect application for caching.

Why is this considered "radical"?

Except for it's architecture, which seems slightly more pluggable than the ASP.NET's, this seems pretty much exactly the same as the ASP.NET's caching layer. Not to mention ASP.NET supports automaticly invalidating cache-dependencies.

Making this pluggable to support both ASP.NET and memcached, would be a simple matter of writing a wrapper class and defining a simple interface. Should be done in about 30 minutes with minimal loss in features.

This has been around since at least 2002. So I'd hardly say there is anything radical about this.

Reply on news.ycombinator.com