September 2007
11 posts
optimising rails
jerakeen: I'm trying to speed up a rails app here, and I've been making some assumptions that I've realised may not actually be true.
jerakeen: Specifically, if I have a list of IDs, I've been assuming that 'ids.map{|id| Model.find(id) }' is going to be slower than 'Model.find( ids )' because the latter will only make one SQL call.
jerakeen: but this is because I'm used to perl, where the ORMs are stupid, the language is fast, and the DB is _always_ the bottleneck
jerakeen: I find myself wondering, though, if the always-different SQL produced by the latter call is going to be less cacheable, and therefore slower, than the many smaller, and much more cacheable calls produced by the first.
otherguy: wow, that's a good question. I'd love to know the answer.
otherguy: have you tried benchmarking it to see if there's a difference?
jerakeen: unfortunately, I know that the live environment has memcached running and all sorts of cleverness
jerakeen: but I'm just running a trivial little dev server here
jerakeen: so I know what the answer will be here - the second approach makes less SQL calls, and will be faster.
jerakeen: I can't really try random things on live, though.
otherguy: you could set up a prod environment on a virtual machine though
jerakeen: I guess I'm going to have to learn how the memcached setup works.
jerakeen: I know I've been warned off making joins in find() calls in the past because it hurts the query cache.
jerakeen: otherwise this would never have occurred to me.
Mobile Safari domain names
Now there are two Mobile Safari using devices, iphone.domain.com as an alternative to m.domain.com for mobile devices doesn’t work any more. I think I’ll suggest i.domain.com as a worryingly compelling alternative..
Read and post comments |
Send to a friend
(via Tom Insam’s blog)
