From: Avdi Grimm <avdi@...>
Date: 2008-03-18T23:30:01+09:00
Subject: Re: Ruby "Speedup" hints?

On Tue, Mar 18, 2008 at 6:43 AM, Marc Heiler <shevegen@linuxmail.org> wrote:
>  Personally I like such simple truths. :)

The problem with simple truths is that often aren't simple, and almost
never stay true.  There was/is a large percentage of hackers in the
C/C++ community who learned certain "simple truths" about how to make
programs go faster - and continued to use them religiously for
decades, even after the compilers had made those techniques irrelavent
or even detrimental.  I believe the same has happened in Java, as
JITing and other optimizations have made a lot of assumptions about
performance moot.

The other problem with "simple truths" is that in performance, it
really isn't true that every little bit helps.  I can't tell you how
many times I've seen a design which was complicated and obfuscated by
some coder's (potentially superstitious) beliefs about certain
techniques being faster than others (e.g. "always avoid dynamic
dispatch"). Almost invariably it turns out that the real performance
gains to be made are algorithmic and/or have to do with IO, and are
orders of magnitude larger than tiny gains made by following
performance "truths" - to the point that the latter gains are lost in
the statistical noise.  It's often the case that those little
rule-based optimizations only served to make the code more difficult
to refactor, and thus harder to apply the real optimizations to.

At a time in Ruby's history when it's implementation is in flux, and
there are multiple alternate implementations coming on line, I think
it is very dangerous to start compiling "rules of thumb" or "simple
truths" about Ruby performance hacks.  And when such rules are stated,
they need to be quantified with benchmarks and qualified with very
specific information about the platforms those benchmarks were
gathered on.

...and then you should *still* write your code to be clear and
well-factored, and put off any optimizations until after you profile.
Chances are you'll discover that your real slowdown is in IO, or in
some database interaction, not in instantiating objects.

I saw a pertinent quote the other day:  "It is easier to optimize
correct code than to correct optimized code." --Bill Harlan

-- 
Avdi