It's good to see members of the Rails core team taking performance seriously. I've been on a personal performance quest for the last couple of years, and what I've discovered is that the Rails community as a whole (not necessarily the core developers, but just people producing Rails-related software as a whole) really seems to consider performance to be something of an afterthought. There is a <i>lot</i> of low-hanging fruit laying around that could substantially improve quality of life for the entire Rails ecosystem if people would put a little time into profiling their stuff and eliminating hotspots.<p>It's been very discouraging to me to see responses to performance issues that range from lukewarm to plain "I don't care". The Rails community could benefit a lot from a visible push by the core team to make performance a priority.
Quoting @tenderlove: "I think we can make the next release of Rails (the release after 4.1) the fastest version ever."<p>I'm glad to see the gradual progression since 3.2 stable!
Props for Aaron's continuous work on <i>mature</i> optimization of Ruby & Rails. I recall his yeoman's work on Ruby dtrace probes and Rails initialization time.
I applaud anyone trying to improve performance. It is discouraging, though, that it only helps with some of the fastest and most efficient queries: direct SELECTs by ID without any joins or LIKE statements.<p>For those interested in good caching without bypassing parts of ActiveRecord, Memcache + Dalli (gem) is a great solution. Caching is not always the right solution, though. Sometimes the best choice is reversing how you get to that data or optimizing your query directly using SQL.
I am skeptical as to whether the calls speeded up by this optimization form a sufficient portion of the actual call time of any actual real world apps actions, such that this optimization will have any non-trivial effect on a real world app.<p>It might. But I definitely wouldn't assume it does. Micro-optimization.<p>Of course, it doesn't hurt either way, unless it does in code complexity, or opportunity cost.
This seems to be but a first step - it's currently limited only to calls of the form `Article.find(id)` and `Article.find_by_xxx(value)`.<p>e.g. `Article.where(xxx: value)` or `Article.where(xxx: value).last(3)` will not benefit from this improvement yet.