

The Cost of Ruby 1.9.3's GC::Profiler - joegaudet
http://jamesgolick.com/2012/11/19/the-cost-of-ruby-1.9.3-s-gc-profiler.html

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

~~~
wpeterson
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...](https://github.com/newrelic/rpm/blob/master/lib/new_relic/agent/stats_engine/gc_profiler.rb#L94)

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

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

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

~~~
cheald
Sure. The biggest change is that it's moving from object marking to bitmap
marking[1]. This makes it CoW-friendly, which should make forking far less
painful (and much faster; copying all those memory pages takes time!). Bitmap
marking can take advantage of parallel marking; Narihiro Nakamura (who did the
new GC work for 2.0) has said in an interview[2] that as a result of parallel
marking, he's managed to reduce GC time by 40% on dual-core machines, and the
hint is that it may be possible to reduce it even further on machines with
more cores.

I don't have benchmarks to share, but Nakamura is a very smart guy, and if he
says he can get it, I have no reason to doubt it.

[1] [http://patshaughnessy.net/2012/3/23/why-you-should-be-
excite...](http://patshaughnessy.net/2012/3/23/why-you-should-be-excited-
about-garbage-collection-in-ruby-2-0)

[2] <http://www.infoq.com/news/2012/01/bitmap-marking-gc>

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

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

------
headius
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...](http://www.slideshare.net/CharlesNutter/why-jruby-
rubyconf-2012)

------
ice799
lolruby

