There clearly still are performance problems in Rails 3.0.x that aren't fixed. I am just now in the process of switching an application to Rails 3 and I have re

There clearly still are performance problems in Rails 3.0.x that aren't fixed. I am just now in the process of switching an application to Rails 3 and I have recently spent 5 days of hard work trying to investigate a big performance drop after the migration (under a different environment: Ruby 1.9.2 and PostgreSQL). I ended up finding two big performance issues in Rails PostgreSQLAdapter: https://github.com/rails/rails/issues/398 https://github.com/rails/rails/issues/398 https://github.com/rails/rails/issues/485 https://github.com/rails/rails/issues/485 What they and everyone else experiencing performance problems should do, is to find one action that has the biggest performance difference between running under Rails 2 and Rails 3 and then profile it - easiest way is by wrapping the action in an around filter and using RubyProf. If there is a obvious performance problem somewhere, you will most often see a method that has a really huge number of calls and %self% time in comparison to all the others. Then you have to figure out what in detail happens - I ended up doing this by putting "begin; raise StandardException.new; rescue => e; puts e.backtrace; end;" into the "hot" methods to get call stacks and then went on to read the code involved.