Yukihiro Matsumoto wrote:
> Hi,

> (2) Although Ruby runs slower than other languages in those
>     micro-benchmarks, real bottleneck in the most application lies in
>     either network connection or databases.  So we don't have to buy 5
>     times as many boxes.

Allow me to rant on what we performance engineers do for a living ... :)

Most web applications I've encountered are not engineered for
performance -- *ever*. There's this little slogan they teach
programmers, which I've heard repeated numerous times on this list:

Beware premature optimization.

As a performance engineer, I don't consider premature optimization a
sin, of course. But leaving that aside, what it translates to is "make
it work, then make it pretty, then deploy it." Once it's deployed, it's
faster to "throw hardware at it" than it is to do the performance
optimization aka performance *re-engineering*.

Incidentally, the person who coined that slogan, Edsger W. Dijkstra,
said also that programming should separate the concerns of correctness
and efficiency. He *never* said to *only* worry about correctness. Part
of the discipline of programming is to pay attention to the efficiency
in equal measure to the correctness. That somehow seems to have been lost.

OK ... on with the rant: :)

1. Those of you who claim to be doing "test-driven development": If
performance testing isn't part of your test-driven development, you
aren't *really* doing test-driven development.

2. Micro-benchmarks are important. A few weeks ago, I ran and profiled a
micro-benchmark on "Matrix", which I posted to the YARV mailing list and
on my RubyForge project page. It's four times as fast in YARV as it is
in Ruby 1.8.5.

Whether it's YARV or some other low-level implementation techniques
really isn't important. What *is* important is that the Ruby "inner
interpreter", to borrow a term from Forth, *must* be as fast as it can
be given the other design constraints like compilers and portability.
The way to achieve this is with profiling on micro-benchmarks.

3. The future of "throw hardware at it" is multi-core processors and
storage array networks (SANs). If you aren't designing your applications
to take advantage of multi-processors, or if you aren't paying attention
to the "lower-level" I/O characteristics of your applications, they're
going to throw hardware at someone else's code.

Speaking of throwing hardware at it, there are ways to know what *kind*
of hardware to throw at it. Learn them. :)

4. An application with a network bottleneck is very often poorly
designed. One of the goals of performance engineering is *minimizing*
the amount of traffic between the client and the server.

Of course, if you're streaming audio, displaying high-definition video,
etc., the network traffic *is* the application, but an on-line banking
application should *not* have to send back more than a couple of
kilobytes to confirm that I've made a payment.

5. Database "bottlenecks": Most of the "industrial strength" databases
-- Oracle, PostgreSQL, MySQL, SQL Server 2005, DB2, etc. -- are
co-optimized with the operating systems and the platform hardware.
They've done their homework; they've done their performance engineering,
profiling and micro-benchmarking.

As good as they are, a poorly engineered database schema can make the
RDBMS work much harder than it needs to, requiring more hardware than is
necessary.