Learning on Ruby’s Method Cache
- Wicked Good Ruby 2013 – Understanding Ruby’s Method Cache
- Speakerdeck – Understanding Ruby’s Method Cache
Just watched the above explanatory video on ruby’s method caching. Maybe it’s a little old topic which is mostly about ruby 1.9 change, but it was a nice resource for me (which means I didn’t know much about this topic).
It talks about the ruby’s dynamic method resolution, and how MRI is implementing the caching of method dispatch, like the following.
- Ruby allows defining methods dynamically and it’s required to check the class and module hierarchy every time methods are called. To alleviate the cost, method caching is introduced in ruby 1.9, but yet there is performance penalty in defining methods due to cache busting.
- The method cache is maintained globally with a generation counter, and once generation is incremented, all the cache becomes invalidated, and need to pay the price again. Even a innocent-like OpenStruct.new internally defines singleton method, and causes the expiration of global cache.
I didn’t know the caching is maintained globally, and the blog post (MRI’s Method Caches) is talking about improving by limiting the scope. Also, I can see the JRuby’s doc (JRuby Internal Design) talks about caching too, and I need more research on this one.
This kind of dynamic feature and mutable nature of the language is a major advantage of ruby, but the performance penalty also comes with it. With this in mind, the immutability in core framework sounds more like an interesting approach, as Scala or Elixir(Erlang) is advocating.