RailsConf 2011: Aaron Patterson, "Double Dream Hands: So Intense!"

…ic 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. You can see his talk here: link to this video 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.…

I don't want to be defending the OP's position, but. . . settings.py is a mess. Even Simon's written a post bashing it ( link ). I cringe a little starting up a project and having to dive into the settings.py file. In some ways, Django tries to be flexible, but it's clumsy. For example, you can have your templates in your app directories. So, you have /path/to/project/posts/templates and /path/to/project/people/templates. However, you can't just put your templates in there because Django doesn't namespace them. Like, if I do {% extends "people/base.html" %} it will look in both those template directories for a people folder. It won't be like, "oh, I should look in /path/to/project/people/t…

In Aaron Patterson's recent "Double Dream Hands: So Intense!" presentation0, he came to the conclusion that Rails 3's slowness is because MRI sucks at GC on a deep stack depth. The average stack depth of Rails 3 applications is ENORMOUS. He mentions in the video that he rewrote the Rack API to pass a mutated var to the next piece of middleware in the Rack chain instead of calling the next middleware and passing an env var to it. The gains were pretty impressive. Hopefully, they make this change to the Rack API for Rails 3.2. That change + the 1.9.3 fix for requiring files1 should result in much faster overall Rails performance. 0 link to this video 1 link

As the number of Rack middleware pieces in a base Rails app grows, it gets slower. MRI and YARV spend a lot more time doing GC as the stack depth grows. Aaron Patterson mentioned that he was working on a modification to the Rack API where each piece of middleware did not call the next piece, reducing the stack depth and drastically improving the runtime performance of Rails apps. Here's the video where he talks about it (towards the beginning): link to this video

Nice article, Jose! For those interested, Aaron Patterson (tenderlove) talks about this in his RailsConf talk, starting at 26:45. link to this video