Comment

Comment by bwilliams

Great article, memoization is pretty complex and full of trade-offs. We recognized a lot of these same pitfalls as we worked through making memoization a consistent and common pattern in our (very large, monolithic Rails) codebase via a `memoize def...` helper. The `false` and `null` pitfall is _surprisingly_ common, enough that it (and other pitfalls) warranted us writing our own memoization DSL.

We took the opposite approach of most libraries though (and a reason we rolled our own instead of pulling in an existing gem) by avoiding handling the complex edge cases that hide trade-offs:

1. Class methods can't be memoized.

2. Methods with arguments can't be memoized (so no LRU caches, weak refs, tracking arguments, handling default args, hash/deep object equality, etc)

The thought at the time was that those more complex scenarios deserve more thought than "prefix it with `memoize`". It's been a few years since we introduced the helper and after seeing it all throughout our codebase with no issues I'm even more confident this was the correct decision.

I haven't revisited it in a while, but I'd love to add some extra niceties to it, like hooking into `ActiveRecord`s `#reload`, although I dislike memoizing in models.

parent bwilliams 1 year ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton