As Christopher points out, there has been quite a bit of discussion in recent weeks about language performance in general, and Ruby performance in particular. While the conversation has proceeded along fairly predictable lines – non-Ruby folks challenging the performance, Ruby folks defending their language of choice – the debate has been notable if nothing else for its essential civility. Both sides, in my opinion, are to be commended for keeping the discussion in rational territory, and (mostly) avoiding the submerged reef of a flamewar (Joel v DHH excepted).
On the question of performance itself, I actually have little to add. Joel kicked this whole thing off by damning Ruby for its lack of performance (among other things), and closer to home Christopher backed that up with a quick example. Against this evidence, even the Ruby advocates were inclined to cede the point:
- IBM’s Rick DeNatale allowed that performance was an issue, but ultimately concluded that “Ruby performance today is surprisingly acceptable for a wide range of uses.”
- Steve Yegge, who has arguable grown to be Google’s most visible blogger, wrote the following: “If only it performed better. *Sigh*. Well, its performance is in the same class as Perl/Python/JavaScript/Lua/Bash/etc., so there are still plenty of tasks Ruby’s admirably suited for.”
- Most significantly, David Heinemeier Hansson (AKA DHH) – the father of the framework that is more responsible than anything for Ruby’s resurgence, Rails – even described a circumstance where they rewrote a Ruby function in C, for performance reasons:
We did the exactly the latter for Campfire. It has one clearly defined bottleneck. Hundreds of users polling every three seconds for updates. Originally the polling mechanism that handled that was 100 lines of Ruby. We rewrote it over a few hours to 300 lines of C. So we got to keep 90% of the application in Ruby and then we outsourced the bottleneck to C. Writing the entire application in C just so we could get the maximum performance from the polling service would have been madness, so I’m glad we didn’t have to choose.
In the face of such evidence, it’s my opinion that trying to defend Ruby’s performance against closer to the metal languages such as C or C++ would be pointless – and I suspect that folks on both sides would agree.
So if the question is not whether or not Ruby performance is less than impressive, relative to some of its non-dynamic competitors, what is it? Whether that matters, of course.
In his del.icio.us comment on my dynamic language piece regarding, Christopher asks just that question, saying “does performance matter or not?” Between that bit, and the comment here:
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).
It seems safe to assume that he’s a bit frustrated by the lack of attention to the dynamic language performance (Smalltalk excepted). And perhaps he’s right to be. Oldtime Smalltalker John Duimovich echoes that frustration in his post, “Performance is not optional.”
Personally, I do not agree. Performance does matter, but it is absolutely optional, in my opinion. If it wasn’t, we’d still be building everything in Assembler [shudder]. The success of the dynamic languages is, as far as I’m concerned, all the proof I need of this truth. Is C++ faster than Python, Ruby, et al? Undoubtedly. Is it the right choice for every development task? Not if adoption trends are any indication.
In open source, there’s a school of thought that says that commercial support is best understood as a money to time ratio. At certain points in a firm’s lifecycle, they’re willing to trade time for money (i.e. startups with no money) – at others, they’re more than happy to trade money for time (i.e. well capitalized firms with lots of backlogged work). I see the language debate as a derivative of this. For some tasks, it’s far more suitable to trade time for performance, at others, performance is the premium while time is more expendable. [1] [2] As DHH puts it,
I don’t hear a lot of people claiming that operating systems should be written in PHP. Or that guest books should be written in C. It just appears self-evident that you pick from the sphere of reasonable applicability.
Different tools, different jobs. And so on.
This does not mean, however, that dynamic languages get a free pass. Ted’s right; contentment with the “outsourcing” approach of in-line method caching is potentially dangerous, as it can come across as indifference to language performance. Fortunately, I would not characterize the reactions that I’ve seen as contentment; quite the reverse, if anything. Grudging acknowledgement, along with constructive responses, has been more the norm from where I sit.
Along with many of the other participants, I fully expect Ruby – along with the other dynamic languages – to improve its performance considerably in the days ahead. Not least because there are firms large and small that will continue to draw attention to it. But in no way, shape or form do I believe that performance and performance alone should be the deciding factor in all language decisions. Performance is important, but optional. Performance, after all, is the basis for speed. Speed, you may recall, is just a feature. Features, as it happens, are (or should be) dictated by requirements – not assumed generic assumptions.
[1] The argument could be made, in fact, that given that in many contexts time is money, the argument is not a derivative but in fact one and the same. This would needlessly complicate the point, however, and thus I leave it as an exercise to the reader to determine where they stand on that point.
[2] Astute readers will note that I’m implicitly making the argument that dynamic languages are more productive – the time portion of the above equation, than their static counterparts. I’ll admit readily that this is a gross oversimplification, and one complicated by tool questions, but I think it’s defensible enough, at least on a superficial basis.
