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

What Hacker News said

Recommends maercsrats · 2011-07 · on “Rails 3.1.0 to be released on 22nd August”

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. You can see his talk here: [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 M

Cites mdasen · 2011-07 · on “Ask HN: Where is the Django community?”

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

Cites getsat · 2011-09 · on “CoderTalk - Episode 5. Has Rails Lost It's Rails? Slow Rails Test, etc.”

In Aaron Patterson's recent "Double Dream Hands: So Intense!" presentation[0], 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 files[1] should result in much faster overall Rails performance. [0] [this video] [1] [LINK]

Cites getsat · 2011-12 · on “Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped”

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): [this video]

Cites jonsmock · 2012-06 · on “Why your web framework should not adopt Rack API”

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