Rails master is now 4.0.0.beta; Ruby 1.8.7 support dropped

Post by maercsrats » Thu, Dec 22, 2011, 5:06 PM UTC

getsat wrote: post #6

evdawg wrote: post #2

Rails needs to do a release solely focused on speed. Dropping 1.8.7 is a good step for a lot of people, but I feel Rails itself has gotten slower since 2.x and I know a lot of people would agree with me. I do a lot of work in CodeIgniter as well as Rails (w/ Ruby 1.9.2 in production), and there's no doubt that my CodeIgniter apps on slower servers with little-to-no deliberate optimization are faster than my Rails app…

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…

Post by bronson » Thu, Dec 22, 2011, 5:29 PM UTC

silversmith wrote: post #9

getsat wrote: post #5

Earlier quoted context omitted.

There's also rbenv, which doesn't override your shell functions or require modifications to your deployment code. Patching basic shell functions like "cd". In 2011. I seriously hope you guys don't do this. Here's the rbenv project page: https://github.com/sstephenson/rbenv#readme It's functionally equivalent to rvm minus the aforementioned negatives.

Except it does not handle neither installation (available via ruby-build), nor gemsets (has a plugin).

Post by getsat » Thu, Dec 22, 2011, 5:53 PM UTC

maercsrats wrote: post #12

getsat wrote: post #6

Earlier quoted context omitted.

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…

I think part of the problem is that rails isn't really RESTful. Here is a good talk about it: http://confreaks.net/videos/699-rubyconf2011-resources-for-r... Dropping the rails router, controllers and rack in favor of something like webmachine and resources could potentially speed up rails and reduce the conceptual complexity as well as the stack depth.

Post by joshbuddy » Thu, Dec 22, 2011, 6:02 PM UTC

maercsrats wrote: post #12

getsat wrote: post #6

Earlier quoted context omitted.

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…

I think part of the problem is that rails isn't really RESTful. Here is a good talk about it: http://confreaks.net/videos/699-rubyconf2011-resources-for-r... Dropping the rails router, controllers and rack in favor of something like webmachine and resources could potentially speed up rails and reduce the conceptual complexity as well as the stack depth.

Post by moe » Thu, Dec 22, 2011, 7:27 PM UTC

cvshepherd wrote: post #7

evdawg wrote: post #2

Rails needs to do a release solely focused on speed. Dropping 1.8.7 is a good step for a lot of people, but I feel Rails itself has gotten slower since 2.x and I know a lot of people would agree with me. I do a lot of work in CodeIgniter as well as Rails (w/ Ruby 1.9.2 in production), and there's no doubt that my CodeIgniter apps on slower servers with little-to-no deliberate optimization are faster than my Rails app…

> For just one particular example, I have found rendering partials in Rails are such a point of poor performance that I have often found myself avoiding it. A good caching plan obviously helps with these kinds of issues. > There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance. In the case of Controllers, inheriting from Ac…