Tuning, rubys, and magic
By Jacob Kessler on Sep 23, 2008
Of course, having a complete and working bit of code isn't enough. We need to make it run fast, too.
So, while I can sometimes go through and make changes that cause (according to my inexpertly applied usage of faban) 15% performance boosts and bring the dynamic pool up to 10% faster than native mongrel with a single runtime, at some point larger tools are needed. The good news is that with additional tuning, the pool should only get faster, and faster is almost always better. The bad news is that, like tuning, that doesn't really leave much for me to blog about, since I'm sure that people don't want to read about stripping out variables that were solving problems that have since been solved in better ways.
So I'll talk about the other stuff that I've been doing, which is probably of more interest: Learning ruby and rails.
It seems appropriate that I should know about ruby and rails, since even though GlassFish isn't written using either, understanding the things that my code will be used for seems like a Good Idea. I came to Sun having never touched ruby code before and my only experiance with rails being from my softwre design class, where one of the other groups in the class opened their presentation of their software product by saying "We started out writing this on top of ruby and rails, but it didn't scale at all so we switched to Java". I've now written a basic rails app (It's an online store. Why is that always the example project), and I feel like I at least moderately know my way around ruby and the rails framework, though I'm sure that there are still tricks waiting to be discovered. I've also learned enough to figure out why the rails app that I mentioned above wasn't scaling, and if I could go back in time I could explain how to fix their problem.
Thus far, the overriding feature of both ruby and rails that I have noticed is the amount of magic present compared to what I'm used to. Of course, I mean that in the original, positive way: both ruby and rails abstract away a lot of the stuff that Java requires you to put in, which definitely makes things easier. A lot of that comes from the focus that both ruby and rails put on convention over configuration, which allows it to "just work", which makes me wonder if there are some unconventional, but useful, things that might break the magic and plunge a hapless programmer into a dark and gritty non-magical world of horrors, but I haven't found any yet. There is definitely room for debate for magical (easy to use and fast) languages vs. non-magical (powerful, easy to optimize) languages, and the answer is probably that different languages are better for different things. This, of course, means that the inside of jruby is that much more impressive, since it is essentially implementing magic in a profoundly non-magical way.
 In all fairness, my group did end up in a similar situation, except that we said "We started out writing this in perl, but then realized that object-oriented perl is painful to write and debug, so we switched to Java"