The elephant in the room is that programmers can't put the importance of execution speed into perspective 
There isn't a lot of discussion on the Ruby list because execution speed isn't the biggest issue for most people.
However, when execution speed *is* an issue it can be a bad bad thing.
···
---
Anyhow, here are a few random thoughts (with some real numbers) around the issue.
---
First off. Premature optimisation. We've all heard of it, even heard that's it is bad. Okay. Quick quiz. Which loop is faster?
#1
for i in 1..(a.length - 1) do
... do something to a[i]
end
or
#2
a.each { | thing | ... do something to thing }
or
#3
for thing in a do
... do something to thing
end
??
In Ruby 1.6.x #1 was a bit faster than #3 which was a lot faster than #2
(When I replaced the 'each' loop form in xampl-pp -- an XML pull parser that I wrote -- with the 'for ... in' loop form the throughput of the parser was increased by 2-4 times).
In Ruby 1.8.4, #3 is about 15% faster than #2 which is quite a lot faster than #1
(So, I know how to speed up my parser, but I have not done this yet... it is working well enough and because the real speed up is to go to libxml or something).
So. What happened? What we consider to be idiomatic Ruby is now only a little slower than non-idiomatic Ruby. What would have happened if the community had *really* regarded execution speed as a primary criteria? We'd have a different idea of 'idiomatic' is what.
Ruby's focus is on something other than performance.
---
So what happens when speed is important and you've already optimised your algorithms? These days you move out of Ruby. That's your only option. I thank Zed for doing that with Mongrel -- it makes a big difference.
Would a VM have helped? Sure. Sufficiently? I doubt it. Java is what, ten times faster than Ruby? Lets say. Is that sufficient to actually solve the problem?
Not for a lot of the examples that come up.
Definitely not for me.
---
Here's an example. I've got a system written in Rails that is a kind of multi-user authoring tool that runs as a webapp. My customers build multiple inter-dependent websites using it. Publishing takes anywhere from 7 to 45 seconds. This is Rails we are talking about here... nobody gets to do anything while that publishing is going on. There are a number of ways to alleviate the problem (in particular async publishing using DRb or something like that).
Thing is, I got bored last weekend and decided to re-write the main culprit in Common Lisp. I'm using the liquid templating system because it is simple, my customers like it, and you can't change any data when using it. But it is slow (with respect to my applications requirements) -- I *still* *recommend* it. Common Lisp is roughly the speed of C++, maybe a tad faster these days (actually, on OS X with that obnoxious gcc 4.x error that prevents compiling at higher optimisation levels than O1, CL is quite a bit faster than C even -- but lets not go there). The CL version of liquid was more than 120 times faster than Ruby -- and I did *nothing* to optimise the code. That's publishing in less than 0.4 seconds in CL, 45 seconds in Ruby, and lets be generous, 4.5 seconds in Java. Java doesn't solve my problem. I doubt a VM for Ruby would either.
What am I going to do? Well, first off, async publishing using DRb. If I still have a problem I'll rig up something with CL. No, I'm not going to jump straight to CL (and just to be crystal clear here, I like CL just fine, and I like Ruby just fine -- I've just got other higher priority things than raw execution speed to consider).
---
Lets talk a little more about webservers. I've written a lot of Java based web applications over the years. I had a new webapp I had to write and I was more than a little concerned with performance in Java. I had prototyped something but it was horribly complex trying to minimise page generation (it was a completely dynamic site, also involving the construction of multi-page websites). So I wrote the thing in Common Lisp in the end. Two things: first, it generated the pages so quickly I didn't have to optimise anything, it was quicker to just re-generate; second, I used TBNL (slightly modified lisp framework) to serve the web-pages -- it was able to sustain about 70M/s in CL vs about 15k/s in Java (I thought I was going to have a heart attack, that's more than 4500 times higher throughput).
What's the point? Well, that how you do things can be pretty important. RoR is roughly the same throughput as my java applications have been -- even using Webrick, and Mongrel is faster still -- assuming no long-running operations. Also, I still don't do everything in CL.
---
The trouble with Ruby is that there are situations where some low-level operation is being executed so often that it becomes the problem. For example, my XML parser string manipulation is the main consumer of time -- lots and lots of calls to pretty quick methods (Sam Roberts' example in this thread of string compares shows the problem, string comparison can be faster than a method call, yet still be responsible for most of your execution time). I don't have a solution for this. *Maybe* a VM will help with this but I'm not really sure of that.
I also have my suspicions about garbage collection in Ruby. I may be wrong to suspect GC, but you won't need a VM to do something to speed it up.
---
There are trade-offs all over the place here. And aside from using Mongrel, I don't think I've ever chosen a route (in Ruby) where native code was involved. And that includes databases -- I use a pure Ruby thing, xampl (see link below), and don't regret it.
Cheers,
Bob
----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>
xampl for Ruby -- <http://rubyforge.org/projects/xampl/>
