| > how is that not trivial? It could be trivial to implement an optimisation which does this for that exact code. But what are you going to do? Hand-code an optimisation for every similar thing people could write? I implemented a general solution. So it also works through metaprogramming: [1, 2, 3].send(:sort).send(:[], 1)
Through user-defined sorting order: [1, 2, 3].sort_by { |a, b| b <=> a }[1]
When nested: [[1, 2].sort[1], 3].sort[0]
And so on.Note that it also needs to be transparent to debuggers and profilers, it needs to handle multiple method redefinitions (for example what happens if someone redefines the sorting order for integers). It's not a pattern-matching optimization - it's partial evaluation enabled by a new kind of polymorphic inline cache. |
While I appreciate that you solved the general problem, I wonder if there are legs here. Specifically, could one mine GitHub to find automatically common patterns that one could write specific optimizers for, or at minimum, leverage that to learn what semi-general cases are worth optimizing? To my knowledge optimizing compilers already do have effectively handlers for common operations, but I don’t know if anyone has leveraged “big data” to help guide this.
IIRC, various tweaks and optimizations in Java were guided by Sun analyzing their own code based. GitHub is just so much bigger, and polyglot.