Think I'll wait until this non-blocking issue is cleared up:
I created two barebones Rails projects. One with Rails
3.0.7 and the other with 3.1.0.beta1. Both are using
Ruby 1.9.2p180 and SQLite for the db. Running this very
basic script with Rails runner, Rails 3.1 takes twice as
long to load in 3.1 versus 3.0.
. . . on our larger apps, we are seeing 20+ second boot times.
The ruby issue should improve performance of rails 3.0 as well. Given that the parent was comparing two rails versions on the same ruby version, I do think there has been a degradation in rails itself.
I would expect that, rails 3.1 includes more library code then rails 3.1. Now whether or not that's the entire reason, I don't know. Remember the ruby problem is a exponential algorithm, you wouldn't need to include that much more code to cause massive performance.
There is a talk by Aaron Patterson from RailsConf talking about why rails 3.1 is slower than rails 3 and rails 2.3. Basically the rack pipeline is getting deeper. Because rack is so simplistic every request requires you going through that pipeline and back again.
His solution is to break up the pipeline into 3 separate types: generators, filters (for response data), and lifecycle hooks. Doing this brought the speed back up to rails 2.3 speeds and a bit faster in some instances. But those were early numbers.
The interesting stuff happens around the 20 min. mark.
Overall, there are a lot of people who want to make ruby better and faster. Rubinius, Jruby and MacRuby are all examples. There are also people who want to make Rails faster. They are examining the slower parts (active record, rack, etc) and working to make it better.
Xavier's awesome patch was somewhat usurped by a scrappier, yet still effective, one by the core team. I did an investigation and analysis of the story:
Congratulations to the Rails team! My team is building in Rails 3.1 and our tests are showing good results. The new asset pipeline is great and HTTP streaming makes for a much smoother user experience.
