Chris Baus

Ruby performance take two

del.ico.us is being loaded up with links which claim that Ruby is fast enough, performance doesn't matter, and that us C++ programmers are just a bunch of curmudgeons (ok that part's true). But if I had shown a situation where Ruby was faster than C++ ever Rubyist would have seized on it, to show how their favorite language is the beez kneez (or something to that effect).

Ruby has almost as much hype as Java when it was released (there was a time when Java was the "in" language). The discussion sounds almost the same. A lot of C developers said Java was too slow, and Java people said it was fast enough, and in a few months and it would be faster. It took Sun years to come out with a high performance Java VM, and for many applications Java still lags C++. If you want a faster Ruby, be prepared to wait years.

There are two aspects of application performance. Processing performance and I/O performance. Most applications are I/O bound so you can't discuss performance without involving I/O.

User mode threads (which are used by Ruby) can be an efficient way of performing I/O, if, and this is a big if, I/O operations which yield the calling thread are used exclusively. Internally Ruby's SQL layer doesn't use its own read and write functions, and blocks when accessing the database. Therefore, all concurrent processing stops until the database operation ends. Considering that I/O performance is multiple magnitudes slower than other operations, this is a "bad thing."

Larry Wall pioneered a way of language design for Perl called: There is more than one way to do it. As anyone who has ever found themselves in the middle of a large Perl program knows, Perl is a difficult language to read. When there is more than one way to do something, every programmer does it a different way, and they might not even know there is another way to do it. This requires the programmer who reads Perl code to understand more of a very large language, which in my opinion is harder than understanding a small language.

With Python I thought we had learned our lessons from Perl. There is one way to do something, so we all do it the same way (more or less). Ruby is Perl all over again. TIMTOWTDI. Combine that with the code generating magic in Rails and poor concurrency architecture, and you have a platform that really isn't my thing.

After 10 years in this industry, I'm becoming immune to hype. If you haven't noticed the same people that jumped on XP as the next big thing are now jumping on Ruby on Rails. Not sure what that means, but I do think the hype machine is in full swing here.