On 18.03.2008 15:30, Avdi Grimm wrote:
> 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.

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