The Cost of Ruby 1.9.3's GC::Profiler (opens in new tab)

(jamesgolick.com)

70 pointsjoegaudet13y ago12 comments

12 comments

11 comments · 6 top-level

VeejayRampay13y ago· 3 in thread

Very interesting article but the bit about Ruby's GC being a "steaming pile of shit" sounds pretty immature and is really unwarranted. The technical merits of the article alone should be enough for the author to avoid having to resort to such extremities. Just my two cents.

cheald13y ago

The language is a bit offputting, but I think the sentiment is valid; MRI's GC is the source of many woes. Alternate implementations like JRuby get much of their relative oomph from much more mature GC implementations. Fortunately, Ruby 2.0 is primed to really step things up in that regard, and is looking much more promising.

ksec13y ago

I had yet seen any benchmarks of reviews of such indication. Ruby 2.0 is a tiny steps in performance and GC. It would be nice if you could point me to some resources.

1 more reply

astrodust13y ago

Although that's harsh, it really is an awful GC that deserves to be taken out back and shot in the head. Repeatedly.

Of all the things in Ruby that would be the least controversial to fix, it would be the Garbage Collector. Sadly, on a list of the things in Ruby that are sexy or easy fix, the Garbage Collector is dead last.

I really hope Ruby 2 focuses more on performance. Usually it's acceptable, but sometimes it's inexplicably bad.

cheald13y ago· 2 in thread

For what it's worth, I checked Newrelic's gem (which is what I use to monitor my GC), and it does clean up after itself by invoking GC::Profiler::clear after a run.

Still though, that's ugly. There are a number of places where Ruby as a systems scripting language (small scripts, short runtime) really clashes with Ruby as an application language (large apps, long runtime), and the GC seems to be at the heart of most of them.

wpeterson13y ago

Confirmed that this only leaks memory if used incorrectly, standard implementations like Newrelic sample this safely, without leaking memory.

Here's a link to the GC profiling agent code in the Newrelic Agent:

https://github.com/newrelic/rpm/blob/master/lib/new_relic/ag...

hcarvalhoalves13y ago

> There are a number of places where Ruby as a systems scripting language (small scripts, short runtime) really clashes with Ruby as an application language (large apps, long runtime) ...

I guess this sums the problem perfectly.

charliesome13y ago

Instead of writing your own profiler, it might be worth contributing your improvements back to Ruby itself.

Create an account on the bug tracker (http://bugs.ruby-lang.org) and open an issue with a patch attached. I've sent a few patches in to Ruby in the past and they're always pretty appreciative of the contribution.

narsil13y ago

I've been executing long-running scripts that handle map-reduce jobs in production and ruby's garbage collector is by far the worst I've had to deal with. Other python and java processes running similar operations handle this much better. It was equally parts sad and hilarious when I realized that even the GC profiler needed clean up or it would hose our system after a few days.

headius13y ago

MRI does GC runs like they're going out of style. I recently did some comparisons with JRuby and saw 100x more GC runs on MRI, and easily 10x more time doing those runs. GC::Profiler ends up eating a crapload of memory as a result.

Check out slide 37 and surrounding slides. If you're complaining about GC and aren't giving JRuby a shot, you're missing out. http://www.slideshare.net/CharlesNutter/why-jruby-rubyconf-2...

ice79913y ago

lolruby

j / k navigate · click thread line to collapse