Thanks cheald. Will take a look at those. My problem with using the performance tracking tools in the past has always been that I get output like "100k string a

Thanks cheald. Will take a look at those. My problem with using the performance tracking tools in the past has always been that I get output like "100k string allocations," "3500 ActiveRecord objects instantiated," "6000 ActiveSupport methods executed," etc. With so much complexity in Rails, it can be maddeningly difficult to pick a culprit from amongst the 1000 papercuts that tend to slow an app down. Even if we just arbitrarily said "let's focus on whichever method is cumulatively taking most time," we have no reference point for whether Rails could make that method faster or not. The time taken by a method or instantiation is just some number, and whether that number is "good enough" is ultimately a judgement call in which I have little basis for comparison. I hope I'm wrong and that there are some big obvious things to optimize, but when I've gone down these rabbit holes in the past, my experience has been that there's usually so much data and so many pieces things contributing to slowdown that it's hard to find high-impact things to fix. Especially when it comes to a framework as multilayered & complex as Rails.