5 ms·
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 SELEC
by mrcwinn 13y ago
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.
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.
- jrochkind1 13y agothese particular optimizations aren't caching any data from the database. They are only caching calculations internal to AR. So you don't need to worry about using cached data when the actual external data has changed, is one thing. The caching here is only of things that can't possibly change, essentially the output of a function for a given input. Your memcache suggestions are a different sort of thing entirely, which certainly may be helpful for some apps in some circumstances.
- midas007 13y agoExactly. Use both (with caveats), they sit at different levels. It's like cloudflare/varnish/nginx -> rack -> rails -> app -> memcache Anything you can use to take load off the DB, which in turn may hit some sort of blocking I/O call (SSD or HDD) is a very Good Thing (TM). Or a sleeping heroku dyno. ;)
- jrochkind1 13y agoThe optimizations being discussed in OP do not take any load off the db. They only reduce CPU time for AR to calculate what it's going to ask the DB for. Unless I'm misunderstanding.
- midas007 13y agoIsn't the goal that the refactored AR code is basically cleaner, which allows AR query caching to be more mergable? Not asking for the same thing twice (or N-1 or N^2-1 extra times) if has to go over the network is a good thing. Databases often aren't properly configured OOTB, especially when it comes to temporary tablespace and query caching.
- jrochkind1 13y agoSeriously, have you read the OP? The optimizations in the OP do not prevent AR from asking for the same thing more than once. They do not effect how many times AR asks for things at all, as far as they can tell. It is _not_ caching database responses. It is caching internal AR calculations only, and does not reduce the number of times AR asks for things from the DB. Unless I am misunderstanding.