old-website

Many languages use "inline method caching" - that is, a "call_dynamic x_named_method" bytecode is replaced with a "guard_and_call_static 0xfffffff" once the callsite is evaluated. In some languages invalidating this cache by calling a method with polymorphic arguments or altering the receiving class can be extremely expensive, so there are usually second-order optimizations applied. Objective-C: Takes one method pointer indirection / jmp trampoline forever, but caches "selectors" on the class so that they become a simple lookup rather than a full evaluation. See sibling comments for better write-ups than I could find. Most JS runtimes: Trace JITs mean many method invocations are compiled into traces and become either inline instructions or native function calls. Also uses "hidden classes" to implement inline method caching, where the call

The problem with limiting monkey-patching is that it's used extensively and with great variety in Rails (and other popular Ruby projects). Monkey patching, done correctly, will "settle" over time. That is, once your rails app has called all the dynamic finder methods it's ever going to use, and `require`d all of the `active_support` extensions it'll need, it's done monkey patching. Of course, there are programming mistakes that can open a huge bag of worms, such as using `OpenStruct`s. Generally, anything that will smash the global method cache[1] is also going to require the kind of `iseq` deoptimization that this pull is about (in fact, smashing the global method cache is a simple case of deoptimization). This is why deoptimization is so useful - it's almost never going to happen after your app has settled, but it's necessary to main