04 November 2008

Speed Up and named_scope acts_as_taggable_on_steroids Finds

I use the acts_as_taggable_on_steroids plugin for tagging. I've been happy with it, but recently have been adding a lot of searching, sorting, filtering, etc. functionality to an app, and needed the find by tag functionality to work as a named_scope, so that I can have it within a chain of many named_scope finders.

This turned out to be trivially easy to do (without having to copy the SQL and put that into my named_scope). To add a "tagged_with" named_scope to your model that is already acts_as_taggable, you can just do this:


named_scope :tagged_with, lambda { |tags| YourModel.find_options_for_find_tagged_with(tags) }


I've been doing a lot of benchmarking and performance improvements to our SQL as well, and decided to see if this was any different in performance compared to just doing YourModel.find_tagged_with that acts_as_taggable_on_steroids adds. As it turns out, the named_scope version, which is really identical at the core, is faster, especially if called more than once (per thread/Rails request)! Here's the benchmarks to prove it:


Single query/1 Iteration:
user system total real
named_scope 0.040000 0.000000 0.040000 ( 0.045085)
find_tagged_with 0.020000 0.010000 0.030000 ( 0.108233)

10 Iterations:
user system total real
named_scope 0.030000 0.000000 0.030000 ( 0.040282)
find_tagged_with 0.420000 0.030000 0.450000 ( 2.040245)


I repeated these multiple times and got the same/similar results each time. So, for a single query, it's only about 2x faster, but if you start issuing this same find multiple times per request then I believe it's the Rails query caching that kicks in with named_scope, but apparently not with the generic find with all the options (I'd love to hear some commentary on this from someone who knows the details).

Regardless, using a named_scope is nice because now you can more easily chain a tag find together with other named_scope items.

0 comments: