Profiling ruby?

Today on #amarok, dangle suggested me to find something I enjoy to do, so that I can cool off a bit after the waste of time with FFmpeg and the quantity of bugs to fix and correct.

But I admit I lately stopped enjoying most of the stuff I do. For sure FFmpeg was a harsh hit to my morale, but it wasn’t alone, as in xine every time I tried to implement something I ended up with regressions or something that is not even near to the attribute ‘usable’.

Ruby, that is something I still somehow enjoy, maybe because it’s a language I don’t know enough yet, and I like learning new languages, and such an OOP language is something that entice me easily 🙂

So, I’m starting to think about something I might implement in Ruby that might come helpful to someone; an easy thought I have is to write a replacement for app-portage/herdstat (that currently doesn’t work on stable systems, at least on amd64, because it does not build with GCC4.1.1), splitting it out in a ruby extension and an user script (so that I can hook it up on ServoFlame without requiring an actual popen, as I used to do in the previous incarnation of it.

But after writing the tool to parse LD_DEBUG=bindings output, I’m starting to think I actually need to have a way to check if the code performs decently, to avoid obvious errors or performance wastes. Lately I’ve been hooked up with valgrind, and in particular with massif and callgrind; while the first is unlikely to be workable with Ruby itself, the latter could be somehow managed, as PHP, Perl and Python profilers have their converters to callgrind format.

Unfortunately Ruby’s internal profiler outputs an already parsed output, that is okay to read but impossible to use for KCacheGrind for instance.

I looked around a bit, and ruby-prof seems promising, as it does actually write a call tree out.

I haven’t played with it yet, but I might in the next days, at least to relax a bit.

The interesting thing about writing a replacement for herdstat in Ruby is that I remember Aaron spending a lot of time fighting with a decent XML parser, with UTF-8 conversions and with URL fetching.. all things I don’t really have to care in Ruby, as there are almost all embedded in the standard library 🙂

On a totally unrelated note, I wonder when the irony will become reality (because there is almost always a moment when that happens) and Debian users will really have to pay if they want anything done… This is probably why I’d rather not see Gentoo going commercial again, at least officially or semi-officially, as that will likely bring similar, but most likely increased, problems to us.

For who will say that Google’s Summer of Code is something similar to that, I’d just like to say that, for what I’ve read in the admins mailing list, the idea is to use SoC to find new developers, rather than pay people that develops already… and on this, it is indeed useful, as Alex and Victor for instance are going to be very important additions to our Gentoo/*BSD team 🙂