Daniel F. Savarese (2007-03). Rails: A Development Gem (http://www.oracle.com/technology/oramag/oracle/07-mar/o27rails.html).
If you think Java is a memory hog, then Ruby is a sloth. Ruby is completely interpreted. It does not compile down to virtual machine code or native code. However, work has been done to produce various Ruby accelerators, from Ruby-to-C translators to just-in-time compilers. These may not be stable enough to bet your project on, though. Rails advocates claim that Ruby execution performance is a nonissue. They argue that execution time is dwarfed by network latency and that the way to scale your applications is to create multiple Rails instances and load-balance them. [Rails is slow (category)] Even if you load-balance multiple Rails instances, however, you should be aware of a major Ruby idiosyncrasy: it uses user-space threads. In other words, the threads are not preemptively scheduled by the operating system. Therefore, if you run Rails on a server with multiple processors, your Ruby threads will run on only one of the processors. Also, any I/O performed in a Ruby thread will block not only the thread but also the entire process. Another problem is that Rails itself processes a single request to its completion before accepting another request. FastCGI allows you to process multiple requests concurrently. For example, as requests come in, a FastCGI program can hand them off to a pool of worker processes or threads to concurrently process multiple requests. If one request blocks because of I/O, the rest of the requests can continue executing. Rails does not take advantage of this capability and limits the scaling of concurrent connection processing to the ability to run multiple processes.