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

http://weblog.rubyonrails.org/2011/12/20/rails-master-is-now-4-0-0-beta/

by utkarshkukreti • 15 years ago

100 25 15 years ago

weblog.rubyonrails.org

evdawg• 15 years ago

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

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.

There's this red herring (and a pet peeve) that making the framework 'less bloated' by dropping components or making them optional equals performance. You'll even see a comment on this blog post asking which components to remove to improve performance! It doesn't work that way when the core components of Rails remain slow.

While the speed of Rails had Ruby 1.8.7 to blame for a long time, now that it's being dropped I think 4.0 has a unique opportunity to optimize for 1.9 and make a big difference to the overall speed of the framework.

boundlessdreamz3• 15 years ago

When using ree, the time to load an empty rails app is half that of ruby 1.9.3 (for both 3.0.x and 3.2 rails versions) https://img.skitch.com/20111206-xt99xy9m5wsejknn4dnxng1g9m.j...

I haven't compared performance of an application in ree versus 1.9.3 but I have seen reports that 1.9.3 is slower than ree for many apps.

So rails dropping support for 1.8.7 is a bit worrying for me.

Btw ruby 1.9.2 had a huge performance regression related to loading files which made rails apps very slow. This has been fixed in 1.9.3. So you are better off using 1.9.3 if you want to use ruby 1.9.x

justinweiss• 15 years ago

On a pretty large rails app, we switched to 1.9.2 about a year ago. Startup time for our app is much, much worse than it was under ree, but our average response time significantly improved -- we saw close to a 50% drop in the time spent in ruby code across nearly all requests. I wouldn't use slow startup time as a reason to avoid benchmarking your app in production mode against 1.9.x, since it could result in a huge perf boost across the whole app.

getsat4• 15 years ago

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): http://www.youtube.com/watch?v=kWOAHIpmLAI

maercsrats• 15 years ago

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.

cvshepherd3• 15 years ago

> 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 ActionController::Metal and not including unnecessary modules, speeds things up a lot.

In general Rails may be slow in comparison to other frameworks. But that doesn't mean it's too slow. I don't really care if my app only manages 5000 requests per second, versus framework x's 6000 or more on the same hardware.

moe• 15 years ago

I don't really care if my app only manages 5000 requests per second, versus framework x's 6000 or more on the same hardware.

Nitpick: Your numbers are a little off. Rails/REE tops out at around ~300 reqs/sec on a current commodity box (16 cores/16G). This is of course application-dependent and optimization can squeeze it some, but it's a different ballpark.

When you look outside of ruby-land you can indeed find frameworks that will handle your 6000/sec on the same hardware (e.g. twisted, node, some of the evented java-frameworks).

So, depending on what you compare to rails, the difference can easily be an order of magnitude.

awj• 15 years ago

> A good caching plan obviously helps with these kinds of issues.

Caching is suggested far too often and too frequently in the Rails world. The solution to "the default tools for template abstraction are too slow to use" is not "use a difficult-to-get-correct system with concerns that cut across the entire project."

As someone else mentioned, Rails is much slower than other frameworks. It does an order of magnitude less than 5000 req/s. Obviously you can just scale it out and load balance, but that suffers increasing costs from an operations perspective. Aside from per-machine cost, there are peaks where adding more servers requires a big change in your management techniques. Those costs shouldn't be trivially dismissed, and if we can look at reworking our tools to keep most (ideally, all) of the productivity but save on the utilization (read: management overhead), how is that a bad thing?

vinhboy• 15 years ago

Thank goodness for RVM. Can't imagine what I would do without it...

getsat4• 15 years ago

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.

silversmith• 15 years ago

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

prpatel• 15 years ago

In case you guys missed it, there was a recent HN article on the speed improvements in jruby + jdk 1.7. I too lament the slowness of Rails - and before you throw the usual arguments at me about perf being relative and 'good enough' blah blah - the ruby/rails community should have seriously addressed this _long_ ago. I've only started with rails recently (this year) and am experimenting with jruby since my patience has worn thing with ruby's speed.

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

Related Stories