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

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 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.

in “Rails 3.1.0 to be released on 22nd August” · View on HN

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

in “Why your web framework should not adopt Rack API” · View on HN

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

in “Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped” · View on HN

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]

in “CoderTalk - Episode 5. Has Rails Lost It's Rails? Slow Rails Test, etc.” · View on HN

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/templates/base.html". I have to put the template in /path/to/project/people/templates/people/base.html. That's clumsy. urls.py is another flexible/clumsy thing (IMO). Django wants me to write a regexp for the simple cases. It's kludgy to do r'^people/(?P<id>\d+)/?$' just to have a URL with an ID in it. And other frameworks have been able to offer the power of regexps for the case where you want them while making the common cases a lot easier. Django caches certain things and if you try to change it at runtime, well, it doesn't change. Django's reusable apps aren't that reusable. They were a lot more reusable than Rails' apps, but the Rails team has worked on that a lot - especially with 3.1 and how each app can have its own assets (images/css/js) all namespaced and neat and tidy. There isn'

in “Ask HN: Where is the Django community?” · View on HN