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