| It's true that many libraries would perform poorly because of a reliance on method_missing. But what can be made quite fast is code that either uses define_method instead, or uses define_method on the first failed call. In fact, a tracing jit could even make the method_missing case fast by automatically specialising and optimizing missing coupled with a vtable/dispatch table. My forever-in-progress ahead-of-time Ruby compiler uses vtable based dispatch for every method name that's seen in the program at least once, and that's usually most of them (unless people e.g. construct method names dynamically at runtime). To handle method_missing, it creates thunks for each method name and fills the missing vtable slots with those, which is similar to what I suggest above - the next step of dynamically optimising method_missing for called symbols and replacing the vtable thunks would be a relatively minor step in a JIT. I don't think anyone expects Ruby to get dramatically faster in the very short term, but there's lots of opportunity to make most Ruby code much faster in the medium term. I think we'll also start seeing implementations that do things like JIT influence how people write Ruby, because a lot of things won't matter much for MRI performance but will be a huge deal for implementations that uses compilation techniques, so it's possible to get a lot more "compiler-friendly" Ruby while still writing clean Ruby that runs well on other implementations. e.g. the above "define_method on method_missing" basically boils down to (pseudo code): def method_missing sym, *args
raise suitable exception if sym doesn't meet right criteria
define_method(sym, args...) do
... whatever ..
end
send(sym,*args)
end
If it lets an implementation speed up its (ab)use of method_missing enough, you'll see people adopt stuff like that. |