Re: What's more important optimisations or debugging?


"Paul Taylor" <paul_ng_pls_rem@xxxxxxxxxxxxx> wrote in message
news:pan.2007.05.31.16.35.41.638016@xxxxxxxxxxxxxxxx
On Thu, 31 May 2007 12:00:56 +0000, Wilco Dijkstra wrote:


Remember Knuth's golden rules about optimisation:

1. Don't do it.
2. (For experts only) Don't do it yet.

I don't agree with this. For small programs it is easy to implement an
efficient algorithm immediately rather than start with an inefficient one.
It's hard to improve badly written code, so rewriting it from scratch
would be better than trying to fix it.

For large programs it is essential that you select the most optimal
architecture and algorithms beforehand, as it is usually impossible to
change them later. The bottlenecks are typically caused by badly
designed interfaces adding too much overhead.

In my experience well designed code is both efficient and easy to
understand, so it wouldn't need optimization (apart from fine tuning).
In other words, if you *need* to optimise an application, you got it wrong.

What you are describing is what I would image all experienced software
engineers do. But then what do you do if performance isn't good enough?
i.e. wrt the design - you got it wrong. I suspect that's when Knuth's
golden rules kick in. I could of course be barking up the wrong tree -
I haven't read Knuth.

The above rules refer to premature optimization, which is allowing efficiency
considerations affect the design (in a presumed negative way). A similar
quote is "premature optimization is the root of all evil". Neither is Knuth's,
the golden rules are Jackson's, the other is Hoare.

However my point is that you precisely have to design for efficiency as it is
not something you can add at a later stage. And efficiency matters a lot in
the embedded world.

Back to your question of what to do when things go wrong. At that point
you've got no choice but to optimize in every possible way. I "optimized"
a 600K line application by compiling it with the best compiler money can
buy and carefully choosing the optimal set of compilation options. There is
not much else one can do once all hotspots have been removed.

Wilco


.

Relevant Pages

  • Re: C Object System
    ... I would be interested by any feedback from C programmers (with little OO ... C++ can be very flexible with meta-programming which is the modern approach of libraries design ... This obsession with efficiency has some advantages ... but imposes certain constraints to the language, ...
    (comp.lang.c)
  • Re: A 21st Century Apple II?
    ... being as productive as someone using a more modern cross-development ... to do with the "efficiency" of the toolset. ... and particularly the Apple II, is an appreciation of the joy of being ... design, not a better one. ...
    (comp.sys.apple2)
  • Re: Bad design
    ... Treus wrote: ... efficiency is a hallmark of intelligent design and inefficiency is ... of the bloodstream far more efficiently than land mammals do. ...
    (talk.origins)
  • Re: Bad design
    ... Treus wrote: ... efficiency is a hallmark of intelligent design and inefficiency is ... of the bloodstream far more efficiently than land mammals do. ...
    (talk.origins)
  • Re: A 21st Century Apple II?
    ... A modern editor (well, emacs isn't exactly ... to do with the "efficiency" of the toolset. ... the details of your design, then who cares if it takes 20 minutes to ... and particularly the Apple II, is an appreciation of the joy of being ...
    (comp.sys.apple2)