From: Chad Perrin Date: 2007-09-28T23:25:25+09:00 Subject: Re: question on bottleneck of ruby On Fri, Sep 28, 2007 at 12:37:11PM +0900, M. Edward (Ed) Borasky wrote: > Francis Cianfrocca wrote: > > >I agree with Kirk. Ruby's inherent performance bottleneck is also its most > >distinctive feature: the open classes and data structures. There's always > >going to be a limit to how much faster you can do name-resolution at > >runtime, since it's costly to begin with, and you can't deterministically > >predict it. (There are approaches to adaptively predict name-bindings at > >runtime, notably from Smalltalk, and I expect JRuby will be able to > >leverage > >them. But they can ameliorate, not solve, the fundamental issue.) > > Which is why they teach data structures in computer science class. It's > all about fast search, I think. That's one of the big gripes I have with > "lazy" interpretation. If you don't do stuff until you have to do it, it > only pays off if you end up *never* having to do it. :) My understanding is that lazy evaluation can actually be of distinct benefit to simplifying attempts to code for concurrency. I haven't really investigated the matter personally, having little call to write software that would benefit from concurrency, but I imagine that will change in time. That being the case, I will surely enjoy the benefits of lazy evaluation at that time, should my understanding of its benefits to concurrency not prove to be based on faulty information. > > >Bottom line: using Ruby will always be characterized by a tradeoff between > >performance and programmer productivity. This is not a criticism of Ruby in > >any way, shape or form! Productivity is a fundamental engineering value, > >and > >time-to-market is a fundamental quality dimension. Ruby therefore has, and > >will continue to have, a unique value proposition. > > I'm not sure this is a valid tradeoff. The economics of *development* > and the economics of *operating* a large code are two entirely different > subjects. People have "always" prototyped in "slow but productive" > languages, like Lisp, Perl, PHP and Ruby, and then reached a point where > the economics dictated a complete rewrite for speed into C, C++ or Java. > I can think of more examples of this than I can of something that was > developed and prototyped rapidly and then grew by "just throwing more > hardware at inefficient software." > > So ... just like a startup should plan for the day when a big company > offers them the choice of selling out or being crushed like a bug, when > you implement a great idea in some rapid prototyping framework like > Rails, plan for the day when you are offered the choice of rewriting > completely in a compiled language or going bankrupt buying hardware. There are a great many use cases for Ruby where there will *never* come a time that runtime performance is that important. Probably 80% of the code I write, minimum, falls into that category. Under such circumstances, a reasonably quick startup time and a decent algorithm make much more of a difference than long-running performance and a binary or bytecode compiled language with a reputation for performance. That doesn't mean I wouldn't like to see Ruby's performance improved significantly in the future. It just means that if Ruby never approaches the performance of C, or the long-running performance characteristics of an optimizing VM like Java's, it will in no way hamper my ability to put Ruby to good use without having to plan for the day when I have to rewrite everything -- because that day will never come in at least the vast majority of cases. In fact, in cases where rapid coding up front in a way that requires a high level language is very important, and high performance software will become very important given time, my preference would not be to prototype in Ruby (or Perl, or UCBLogo, or whatever) anyway. It'd be to use something like OCaml, with excellent performance characteristics in binary compiled form, decent long-running performance in bytecode compiled form running on its VM, and convenient source code access using the interpreter with the ability to test stuff on the fly using its "toplevel" interactive interpreter. Use a tool to suit the job at hand. A lot of the time, in my work and play, that tool is Ruby -- and will never require a rewrite in a "faster" language. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] John W. Russell: "People point. Sometimes that's just easier. They also use words. Sometimes that's just easier. For the same reasons that pointing has not made words obsolete, there will always be command lines."