Skip to main content

Memoization Discussion

General • Asked by Chris Oliver
Related episode

Great episode! I thought it was similar to Ryan Bate's old Memorization episode. Twitter method call was a great example, but I think it would be even beneficial for viewers if you have another episode where you show the best practices for storing those kind of external api calls in Redis or any other background gems.


I hadn't seen this before, quite an interesting approach. I like the intentions / goals a lot and a good discussion about it. There's a certain elegance to it that feels very clean.

That said, I'm not sure memoization is really necessary for any of this. It might be useful in post_params, but it's one of those cases like name where it's ultra fast to run and only usually gets access once, so unlikely to provide any speed benefits to memoize.

For example, you can just use before_actions to accomplish the same result: https://gist.github.com/exc...

The benefit of instance variables is that it provides you a way at a glance to determine which variables you have access to in your views, plus they're automatically available as well without having to expose helper_methods.

And like the discussion mentioned, for the index methods they tend to have scopes applied often, so I usually find them useful to always be written in the method so you can easily find it, rather than having to look at helper methods or before_actions for that. It makes more sense for member actions where you've always got to set @post for example and it's kind of assumed that it'll always be the same.

What do you think?


Thanks for another great episode Chris! I love this kind of "little tips and tricks" type stuff. Would love to see more caching and performance related episodes. Thanks for making these screencasts :)

Thanks for your support Ken! :D


Please be careful with booleans. Your code only memoizes `true` values. If the result is `false` it will recalculate.
Instead, with booleans you'd better go with something like:
```ruby
def valid?
return @valid if defined? @valid
@valid = expensive_boolean_calculation?
end
```

Yes, great point! Thanks for mentioning that.


Since Twitter was brought up in this video I figured it would be a good place to check in and see if anyone knows of a solid resource or code base for testing against 3rd Party APIs. My specific situation is using the Twitter gem and trying to figure out what to actually test against and how to implement this in Minitest --preferably without mocks or relying upon gems. Any links would be appreciated.


Is there a way to check the size of cache, and is there a way to clear the cache if needed? thks!

The cache only works over a single request so it will be cleared automatically if user make another request


I don't remember if you mention when will the cache result expired and assign new value into it. So that's my question, when will the cache kind of expired? Is it only available over **a single request**?

updated :
From comment discussion here http://www.justinweiss.com/... and here http://railscasts.com/episo... it can be inferred that yes it's only available on a single request


Login or Create An Account to join the conversation.

Subscribe to the newsletter

Join 27,623+ developers who get early access to new screencasts, articles, guides, updates, and more.

    By clicking this button, you agree to the GoRails Terms of Service and Privacy Policy.

    More of a social being? We're also on Twitter and YouTube.