On Tue, Jan 5, 2010 at 9:47 PM, Albert Schlef <albertschlef / gmail.com> wrote:

> Why does everybody say that CPUs are fast nowadays and that "it dosn't
> mattar that language XYZ is slow"?
>
> It does matter: web applications. If your applications can't serve all
> the visitors, then you're going to lose your customer or you'll have to
> learn some other language with better performance.

That's such a red herring that I'm not even sure how to address it.

How about this:

A dynamic web site that's been running a couple years, with all of the
content pulled from a database, and navigation generated dynamically
from db contents, running on a shared server that is a few years old
(i.e. not cutting edge hardware), running on Ruby 1.8.6 (i.e. not a
speedy version of Ruby).

Requests per second:    137.45 [#/sec] (mean)

Make it more complex by pulling a page that renders a big table of
itty bitty numbers for mutual fund performance:

Requests per second:    82.48 [#/sec] (mean)

However, mitigate even those slow speeds by running it behind a load
balancer, implemented with Ruby, that caches the generated pages and
serves them from cache (while the LB is also managing requests for 70
other sites):

Requests per second:    6107.65 [#/sec] (mean)

Sure, performance improvements in the language implementations are
great -- it's always good when our stuff runs faster. But it's absurd
to argue that Ruby, even in the older versions of MRI, can't provide
far more than sufficient performance for _really_ fast web
applications. I made my living writing web software with Ruby for
several years before most anyone else was doing it, and even then, in
that particular application arena, Ruby always proved to be more than
fast enough to render complex web pages in a few milliseconds.

And these days, the landscape is nowhere near that simple.  Look at
Ruby 1.9.x, or JRuby, or Rubinius, and see where the trends are
heading. The future looks good, IMHO.


Kirk Haines