<story><title>Rails 3 Performance - Not Good Enough</title><url>http://blog.tstmedia.com/news_article/show/86942?referrer_id=308069</url></story><parent_chain></parent_chain><comment><author>fauigerzigerk</author><text>I think the real problem with Rails and similar frameworks is the culture of not giving a shit about performance. I would never ever release a new version of anything that is significantly slower than the previous one. It&apos;s simply a bug in my view.&lt;p&gt;But there are people who have convinced themselves that as long as it scales out, it doesn&apos;t matter how many servers you have to run. And if the reason is that something that&apos;s known statically is checked billions of times at runtime they don&apos;t care.&lt;p&gt;For a framework, the concept of premature optimization makes no sense.</text></comment>
<story><title>Rails 3 Performance - Not Good Enough</title><url>http://blog.tstmedia.com/news_article/show/86942?referrer_id=308069</url></story><parent_chain></parent_chain><comment><author>stiff</author><text>There clearly still are performance problems in Rails 3.0.x that aren&apos;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:&lt;p&gt;&lt;a href=&quot;https://github.com/rails/rails/issues/398&quot; rel=&quot;nofollow&quot;&gt;https://github.com/rails/rails/issues/398&lt;/a&gt;
&lt;a href=&quot;https://github.com/rails/rails/issues/485&quot; rel=&quot;nofollow&quot;&gt;https://github.com/rails/rails/issues/485&lt;/a&gt;&lt;p&gt;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 &quot;begin; raise StandardException.new; rescue =&amp;#62; e; puts e.backtrace; end;&quot; into the &quot;hot&quot; methods to get call stacks and then went on to read the code involved.</text></comment>