If I understand the implementation correctly, this seems like it has a low ratio of complexity to performance improvements. It will be interesting to see if this ends up landing in MRI. I'm anxious to see some non-micro benchmarks against "real world" Ruby, which basically means the Rails test suite, start up time, etc.

My only concern would be what kind of impact this has on memory usage. Having all of those in memory copies of method implementations hanging around probably comes at a cost. But in general the world seems to be OK with trading memory for speed these days. If Ruby is twice as fast for less than twice the memory then we can easily consider it a win.

Anecdotally, it seems like servers these days have plenty of RAM to spare relative to CPUs anyway. A semi-recent Rails app that ran on AWS EC2 m4.xlarge's with 24 Puma workers only used 5.5GB of the available 16GB of RAM.

It also looks like the spirit of this optimization comes from the work Chris Seaton and others have been doing with Ruby and the Graal VM. It's great to see work like that having an impact on MRI.