•
•
•
•
Well, I have good and bad news from the Rubinius front. This morning, I built the latest Rubinius from the git repository, and gave LogWatchR another try … and it worked! This is a huge step forward from my perspective, since I’ve had all kinds of wierd failures in the past. The bad news (well, bad is an overstatement, let’s say ‘not so good news’) is that the performance is pretty bad at this
It looks like my post on Ruby 1.9.0 performance is drawing some criticism over on on reddit. I already updated the original post to deal with a comment by ‘gravity’. In a later comment, ‘Ganryu’ wrote “I don’t get it… isn’t this mainly IO dependent?” Since he doesn’t have access to the code for LogWatchR he can’t do the profiling to find this out, but it’s the same kind of assumption that a
One tool that I should have included in my survey, but forgot, is flog, yet another great tool from Ryan Davis and Eric Hodel. flog is like a profiler for your code’s complexity instead of it’s performance1. Why worry about complexity? Well, there are a three good reasons I can think of: If you’re dealing with legacy code, knowing where the real complexity is will help you prioritize your