On May 22, 2006, at 9:50, James Britt wrote: > Kirk Haines wrote: > >> ... >> Ruby can be a bottleneck, but for the vast majority of Ruby users and >> the vast majority of tasks people use if for, it is not the >> bottleneck. >> It is not an elephant in the living room that everyone is ignoring if >> the performance simply isn't a limiting factor. It's an elephant out >> in the paddock, where it belongs in those cases. And those cases are >> the majority of cases. > > Or it's the hamster in the living room. People don't comment on it > because, for the most part, they don't see it. > > Those people having speed issues: Is it not a reasonable option to > replace the bottleneck Ruby code with custom compiled C libraries? In a word, "no." Not for me. I'm a hobbyist programmer, not a professional. I program in order to accomplish something else, or to save time, and I don't spend more than, oh, 4-5 hours a week, on average, programming. I cannot *imagine* what I would *ever* program that would justify learning a whole new language, when I haven't even finished learning this one yet. (I know, one never 'finishes' learning a language. But I still have to look up "Array" and "Enumerate" methods, and probably always will, because I haven't memorized which one does what yet.) On the other hand, it's also amusingly irrelevant for me. I have replaced some of my older code with newer Ruby versions in order to make them *faster.* Ruby's way faster than AppleScript, which is what most of my older programs are written in. On the third hand, I hope the next time this thread appears, nobody will waste time advancing the nearly nonsensical argument that you can always speed up ruby by replacing parts with custom compiled C libraries. Or, to put it another way "You can make Ruby faster by . . . not using Ruby." That might make my *program* run faster, but it didn't do diddly-squat for making *Ruby* faster. And a lot of this thread was occupied by people who were distracted by this right answer to the wrong question. Of course IT departments looking (rightly or wrongly) at the question "How fast is Ruby?" will find this answer inadequate. Of course Zed is underwhelmed by the joy of having to cross-code more of Mongrel from Ruby to C. Of course non-native gems are generally less popular than native ones. None of these 'solutions' make *Ruby* one iota faster. If I use a non-Ruby library, I might be able to make my program go faster, but I'm also incorporating into my program a chunk of code I can't rewrite, or even read. It also makes my program grossly less portable. I can easily transport a 100% Ruby program to another system, and even another platform, as long as they've got the right version of Ruby installed. Alas, the one program I currently need to move to other systems is using a non-Ruby database interface. Fortunately, I only have to move it to other binary-compatible systems, so I can embed the library in my code. For a binary-incompatible system, I'm completely screwed, since I cannot reasonably expect an end-user to install Ruby, Rubygems, this particular gem, AND PostgreSQL on their desktop merely to use this cute little program. The program requires the db driver, compiling the driver requires pglib, and getting pglib involves installing/compiling Postgres. (Or stealing it off some other binary-compatible system, although maybe I just got lucky when I did that. {shrug}) So I encourage people to be mindful that speeding up a _program_ that's written, in whole or in part, with Ruby is not the same as speeding up Ruby itself. It's great to have that option, and sometimes it's the optimal solution, but it's not the same thing. 1. YARV/Rite/whatever appears to be an impending scheme that will speed up Ruby itself. Continuing to refine and improve core Ruby code (whether that core code itself is written in Ruby or C or whatever) is another avenue to speed up Ruby. 2. Effective, easy to use profilers/benchmarkers/analyzers, good/better documentation for same, and/or more/better signs pointing to such tools will help programmers make their own Ruby code go faster. Even if Ruby-the-language didn't get any faster, if the average program, by the average programmer, is more likely to have been optimized (for speed or size or whatever that programmer cares about), that's nearly the same thing: native Ruby code running faster than it used to. 3. Touting or enhancing Ruby's low-friction interfaces to other languages might make programs that incorporate some amount of Ruby run faster, but it also is effectively an admission of guilt. "Yes, Ruby really is as slow as you think it is; my advice is to use something else if speed matters to you." That's fine if/when Ruby really is too slow, but it looks to me (e.g. the counter-example of Rails) that there's lots of 'slow Ruby' that could be faster if the code were slightly rewritten. This seems to be especially true when the specific issue is not "Ruby is too slow to do X" but rather "Ruby is slower than [put name of high-level language, not 'C', here]" Based on this thread, and other messages I've read, Ruby's speed 'issue' sure doesn't sound like an elephant to me. I think it's a cat. For me, Ruby is soft, cuddly, and friendly, and more than rewards the occasional scratches, hair balls, and litterbox scooping. But there are some people with really nice furniture, allergies, and/or a small apartment, and if more practical/useful profilers, or YARV, or whatever can deodorize and automatically scoop the catbox, train Ruby not to scratch the furniture, and cut down on the shedding, then I'm sure they'll be thrilled.