Hi! Long period of time I think about programmatically code optimization for YARV. In compiled languages like C/C++ the compiler can do whatever it wants with the code and does for performance optimization. Firstly, ruby developers think about code readability, secondary about performance. Because ruby translates .rb file into bytecode we can do whit this bytecode anything to win in performance and do not lose in the expressiveness of the code.
But I came to the conclusion that a static bytecode optimizer is not possible, because in translation stage we don't know about which object/class we use. So, did someone think about runtime code analyzing? If we have some type of statistic we can dynamically transform bytecode to optimized version, use optimized version of C functions. Also I thought if we have statistic we can reduce some GC overhead
# before array.map(&:method1).map(&:method2)# if I know for sure that map is not overridden and calls from Enumerable I can rebuild code like this array.mapdo_1.method1_1.method2end
In this example 2 map calls generate one redundant array which will be destructed by GC, so we can transform it to seconds version. It can be applied not only for map/select functions, but many other.
It's interesting that many people seem to think it's what MJIT does. We indeed copy-paste the original C code for most instructions, but it's not for optimizations but just for ease of maintenance. Translating VM instructions to C as is doesn't give any speedup. The speedup by eliminating PC/SP motion is also trivial. C compilers can do some analysis over multiple instructions for their optimizations, but in reality, it's also limited to opt_ instructions. While I'm not sure if you've ever seen benchmarks of MJIT, when MJIT gives a performance improvement, it's often leveraging runtime information. I'm not saying it has done enough of it though.
# before array.map(&:method1).map(&:method2)# if I know for sure that map is not overridden and calls from Enumerable I can rebuild code like this array.mapdo_1.method1_1.method2end
there are differences with the code:
first lets say that array is [a, b]
the first example would call x = a.method1, y = b.method1 and then x.method2, y.method2
the second one would call a.method1, a.method2 then b.method1, b.method2
there is a difference in the order of the method calls, first one would first call all method1 then method2, the second one would call method1 and method2 in sequence
# before array.map(&:method1).map(&:method2)# if I know for sure that map is not overridden and calls from Enumerable I can rebuild code like this array.mapdo_1.method1_1.method2end
@nobu (Nobuyoshi Nakada) Yes you are right, but I want to say that we don't need temp object in this case, so wy can't we do some optimizations? or one more case: code like this [1,2,3,4,5,6].select(&:even?).count will allocate new array only for return his size, isn't it superfluous? one more think I thought: rails programmers love create helper methods like
first example it's simple calculation and maybe we can transform body to inline variant without opt_send_without_block instruction? second example just call other methods, it's wrapper and we can remove this call and use only body.
Yes these are all optimisations that compilers can do and you can see them being done in implementations of Ruby like TruffleRuby, but it requires a complex system of 'deoptimisation' to be able to go from the optimised code back to the full code, in case the assumptions you made when you compiled don't hold any more. You may have to do that deoptimisation while the code is already running.
I think you'd have to do a lot of work, to even get the basic benefits of this approach. So they may not want what is likely to be a very large volume of code for what is likely to be a small benefit.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by