in reply to Optimisation isn't a dirty word.

I mostly agree with your post, and I also agree with most of the responses I've seen. I'm quite enjoying this discussion; thanks for that. There's one thing at the end of your post that I haven't seen addressed, though:

if there are two ways to do something, and one costs less than the other and they are otherwise equal, use the one that uses less

This is pretty clearly true, but I have to wonder how often two things are "otherwise equal." In my experience, there's almost always a tradeoff. Other replies have mentioned specific tradeoffs and examples, but I think it's also good to keep the general idea in mind, and keep an eye open to the balance involved in these kind of decisions.

Replies are listed 'Best First'.
Re^2: Optimisation isn't a dirty word.
by 5mi11er (Deacon) on Oct 25, 2005 at 18:31 UTC
    Ah, yes, thanks revdiablo. I too was getting sucked into the CPU cycle part of the optimization arguments. We all need to remember that there are several dimensions to optimization:
    • CPU cycles
    • space (memory, hard drive) usage
    • maintenance & readability
    • generalization and reusability
    • flexability

    I'm sure I'm missing others, and flexability could arguably be part of the reusability 'dimension'.

    -Scott

[reply]
[reply]

      I almost always favor in order:

      1. maintenance and readability
      2. flexibility, generalization and reuse (if you have to do something twice, you'll need to do it 1000 times).
      3. space
      4. CPU cycles

      99% of the time the last two don't matter. Item 1 matters 99% of the time. Too much focus on generalization will cause you to either write a Turing complete language or never finish your project. Generally, some generality is good (heh).

      Readable, well organized code is much easier to tighten up speed or space than overly tweaked "great idea" and "nifty hack" laden code.


      TGI says moo

[reply]

In Section Meditations