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.
Yes, that's true. But I'm inclined to say that even in Java there is a single operation that is always the most expensive (not counting IO of course) and this is object creation. The reason is fairly simple: object creation has significant overhead (memory allocation or GC, management overhead for GC) which won't easily go away - although Sun has done a tremendous job in improving this throughout the course of JVM evolution!
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.
I could not agree more. In fact, I said the same - just not so well elaborate as you did.
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.
Simple truths are so compelling because they are so simple - but they often are deceptive, too. Just think about the numerous articles about Java performance (e.g. [1]). Yes, people need to take them with a huge grain of salt - at least the Ruby version and platform.
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.
Good point.
..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
Great, I have to print that one out! But wait, after optimization correct code will become optimized code - and sometimes you don't know whether it's still correct (ok, that should be avoided by unit tests).
Kind regards
robert
[1] http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
···
On 18.03.2008 15:30, Avdi Grimm wrote:
On Tue, Mar 18, 2008 at 6:43 AM, Marc Heiler <shevegen@linuxmail.org> wrote:
)