Comments on: Ruby object allocation & why you should care

By: Geoff Tidey

Geoff Tidey — Tue, 03 Aug 2010 15:43:43 +0000

Thanks for a great article. I shall buy you this: http://static2.syswear.com/images/shirts/30/30_folded_large_black.png, when I’ve got some money

By: Rohit Arondekar

Rohit Arondekar — Sat, 31 Jul 2010 01:26:59 +0000

I’m curious as to whether the GC algorithm used in MRI is meant for high performance. What would the effect be (theoretically) of using a different/better GC? Also it would be nice to be able to swap in/out GC’s so that you can use the one that’s perfect for you. /end_crazy_thoughts

Nice article, eye opening!

By: Matt Aimonetti

Matt Aimonetti — Fri, 30 Jul 2010 22:46:29 +0000

It depends what you call “rich” but I agree that mounting Rack/Sinatra apps in a Rails app might be interesting. I did not check the overhead for doing that (if any) since in this specific case Rails’ value isn’t worth the complexity but others might want to look into that alternative.

However, that still doesn’t solve the root problem: Rails allocating too many objects. Also depending on how you do caching, the allocation will still happen and you will spend a lot of time in the GC.

By: Ryan Bates

Ryan Bates — Fri, 30 Jul 2010 21:06:16 +0000

Since Rails adopts Rack, why not use Rails for the feature rich parts of the application and put just the performance critical parts into a Sinatra app or a custom Rack application?

For example, an in e-commerce app there’s usually a lot of complexity in the checkout process but it is not visited very frequently. Leave that in Rails but strip down the home page and other frequently visited pages using rack or caching.

That said, thanks for this article. It is very enlightening and I would love to see object allocation play a bigger role when optimizing Rails and other frameworks.

By: Ryan Bates

Ryan Bates — Fri, 30 Jul 2010 20:57:16 +0000

I think there he is referring to explicit object allocations such as Foo.new. Don’t feel that this is especially heavy compared to everything else in Ruby. What we must be careful with are implicit object allocations such as “foo” in a string.

By: Mike Moore

Mike Moore — Fri, 30 Jul 2010 20:03:09 +0000

I should add that he he was speaking about using Rails, not creating it. I look forward to Yehuda’s response.

By: Mike Moore

Mike Moore — Fri, 30 Jul 2010 19:34:09 +0000

FWIW, Yehuda downplayed concerns about object allocation at MountainWest RubyConf 2010, calling it “essentially free”. This is ~20:45 in the video.

http://mwrc2010.confreaks.com/2010-03-11-13-30-yehuda-katz-writing-modular-ruby-code-lessons-learned-from-rails.html

By: Oldschool

Oldschool — Fri, 30 Jul 2010 17:15:31 +0000

… the key issue is that some libraries/frameworks allocate way too many objects …

I *totally* disagree with this statement. A library should care about performance, usability, stability. Rails does a good job with that (talking about Rails 2.3 and greater). Maybe Rails does create a bunch of objects, but this does change the fact that the Ruby GC *sucks* and is *flawed*. Why do we have so many fixes (REE, Rubinius, …)
What I don’t get, is why all Rubists are so against the JVM. Before I hear the Java Dev argument again. I was a Java Dev, but I am a Ruby Dev (only) for 4 years now. So I consider myself as a Rubist. I truly believe that the JVM/JRuby could be something really great for Ruby/Rails. It is the entry card in the enterprise level (some care about that and there is much money in it), it offers a very fast and mature platform, it is offers the chance to use many libraries like Apache Libs, Google Collections and so on. Why are we against it? Is it because it has the letter “J” in it? The only thing I can think of, are native bindings in Gems. With the help of the community this could be done quickly.

Another thing, as EngineYard took over JRuby, we can now be sure that JRuby has commercial support behind it and is developed by Ruby-understanders (love the word). So again my question: Why are Rubists against JRuby?

By: Matt Aimonetti

Matt Aimonetti — Fri, 30 Jul 2010 16:46:18 +0000

Not really, because of the performance issue caused by Rails3, it looks like the project I am working on will no longer run on Rails. I am still investigating but a switch to a pure rack stack or a Sinatra based solution is more probable. I believe Aman Gupta is looking into it tho.

By: Matt Aimonetti

Matt Aimonetti — Fri, 30 Jul 2010 16:42:14 +0000

The GCStats is a rack middleware, so you need to tell your framework to use the middleware. For Rails, read http://guides.rubyonrails.org/rails_on_rack.html otherwise, you usually just need to require the file and add: “use GCStats” to your rackup file. (usuallly called config.ru)