Posted by rick April 01, 2007 @ 10:42 PM
Stephan Kaes, our resident performance expert, has released a new version of RailsBench. He then created new Rails 1.2 vs Rails 1.1 benchmarks, discovering that things aren’t as bad as they seem. Of course, those numbers won’t mean a whole lot until you read the full report
Ruby on Rails was created by David Heinemeier Hansson, a partner at 37signals,
then extended and improved by a core team of committers and hundreds of open-source contributors.
Rails is released under the MIT license. Ruby under the Ruby License.
"Rails", "Ruby on Rails", and the Rails logo are trademarks of David Heinemeier Hansson. All rights reserved.
|
Sponsored by |
 |
Perhaps not as bad as some say (50% loss in performance?), but still a 10% degradation across the board is pretty significant.
Releasing performance claims (particularly numbers) on April 1st is asking for trouble (at least in the US)
Make Rails proper (In terms of design/code) and let JRuby handle performance ;)
fac – That’s like saying “Make Windows proper (in terms of design/code) and let Intel handle performance” Unfortunately, it just doesn’t happen that way.
I know this post is Rails related but any new word on YARV or any other VM for Ruby that might offer Ruby performance improvements?
YARV has been merged in the Ruby 1.9 which is set for a Christmas 2007 release. See http://eigenclass.org/hiki/non-synthetic-benchmarks-for-yarv for some preliminary Rails benchmarks and http://eigenclass.org/hiki/porting-rails-to-ruby-1.9 about porting Rails to Ruby 1.9.
Porting Rails over to Ruby 1.9 will be a huge task. Especially since ruby will certainly have more parentheses.
Whether or not it’s a huge task, Rails needs to be ported to Ruby 1.9 as soon as it becomes possible. Rails seems to me to be out of its honeymoon phase, and performance isn’t an issue that can be ducked forever. When people complain about Rails’ speed they very often get an eloquent defense about how increased developer productivity with RoR is so much of a win that it makes up for performance issues, but the two issues are completely orthogonal to one another.
There’s also the sinking feeling I got when I learned that Rails’ ActiveRecord implementation can’t do prepared queries, but that’s a lament for another day.
Jake, re “Unfortunately, it just doesn’t happen that way.”
Maybe it should.
fac- But it can’t, and shouldn’t—in any development. Optimization simply doesn’t work when only applied locally. Far better results are achieved when people understand and respect that the decisions they make will have an impact on performance.
I don’t advocate that the developers get caught up in minutiae, but that’s what profiling is for. Run the profiler on a benchmark suite and target the top three “killers” at any given time.
“Things aren’t as bad as they seem” should be the new Rails motto.
Creative
As any technology, speed and performances are often due to design code of developpers.
Thats true with C. The same for Java…
Actually, rails is not the rabbit. But even if the framework is considered by some like a turtle… everyone know the end of the story :)