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.

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.

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.

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.

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

lolruby