3 ms·
Doesn't this thrash the ruby VM's virtual method cache? (It's been ~7 years since I was working on production ruby code, but I remember it being a really painfu
by estsauver 1y ago
Doesn't this thrash the ruby VM's virtual method cache? (It's been ~7 years since I was working on production ruby code, but I remember it being a really painful performance issue for us when using dynamic method missing routing. I might be getting it confused with class extensions though.)
- julienbourdeau 1y agoVery good question! The docs doesn't mention anything (unlike OpenStruct for instance)
- byroot 1y agoNot certain what you mean by "virtual method cache", the Ruby VM has multiple layers of method cache (or call cache) but I've never heard any of them referred to as the "virtual method cache". For the inline call caches in the interpreter loop, they are monomorphic, so if you call the same codepath with the decorator and the actual object, they will indeed flip flop. The second layer of cache is class based, so after the inline cache is defeated you will end up doing a single hash-table lookup on the class. As for YJIT, IIRC it does handle polymorphic call caches, so it won't mind such situation at all unless you have more than a handful of different implementations of that method being called at a given callsite.