The way presented has very high cost of initial creation, and almost negligible setup overhead per user ('user' being a programmer who wants memory use info).
Patching and recompiling has moderate-low cost of initial creation, but also moderate-low setup overhead per user.
Plus, some of us think this kind of thing is just plain fun. :)
I built this because I like working on this sort of thing and because it lowers the bar for everyone else who doesn't know how to or want to rebuild their binaries.
Also, depends a lot on your infrastructure. Sometimes it's easier to distribute and maintain patched Rubies, and sometimes it's easier to just require a ruby gem. The gem is designed and built in such a way that it should be resistant to most changes made to the Ruby VM.
"Click here to download a version of the patched Ruby for OS X". That's as easy, for the end-user, as rewriting the executable on the fly. And it's probably easier for you guys too ;)
I'd completely missed the reusability aspect of things; I guess because the tight coupling to specific addresses would mean redoing a lot of the work for different builds. But once you figure it out, it looks like it could be trivial to replicate for future minor revisions.
And I agree, it's fun stuff! That kind of hacking really makes me smile. I was just curious about the pragmatic motivations.
Sorry, I didn't mean to imply that you had hardcoded the addresses, only that you'll have to go through the process of finding the addresses anew for each build. Not an insurmountable problem (as you've shown), but making it slightly harder to automate.
However, I admit to having had time to only read through it casually, so please take any incorrect statements solely as misunderstanding on my part.
Patching and recompiling has moderate-low cost of initial creation, but also moderate-low setup overhead per user.
Plus, some of us think this kind of thing is just plain fun. :)