[H-GEN] Which is better?

[Greg Black]

On 2004-04-27, Andrae Muys wrote:

> Keep the code simple.
> Get the code correct.
> Measure.
> 
> The normal culprits for code inefficiency are:
> 
> 1) Poor choice of algorithms.
> 2) Poor IO handling.
> 3) Thread-synchronisation/Memory Allocation/Cache thrashing in inner-loops.

It won't surprise anybody that I agree.  But I'd go a little bit
further.  Of the three "culprits" listed above, number 1 is by
far the most important for two important reasons: it's typically
given the least thought during what passes for the "design"; and
it's probably the only area where you might hope to achieve
performance improvements of more than one order of magnitude.

In the real world, nobody cares if some loop can be made to run
in half the time when it only takes a couple of milliseconds in
any case.  What people care about are things like ten minute
response times in interactive applications[1] where what they
need is sub-second responses.  No amount of micro-optimisation
is ever going to achieve that sort of improvement.

The big deal here is to take the time to sit down and think
through the task; then to implement a clean simple solution and
test it until you're certain that it's as good as it can be.
Then, if it fails to meet some required criterion in terms of
performance, take the time to profile it.  If the profiler shows
you that ninety per cent of the time is in one routine, then you
can look at that routine and consider algorithmic variations.
On the other hand, if the profiler shows you that the time is
spent in a large subset of the code, you have to decide whether
the solution is a complete re-think or faster hardware.

Cheers, Greg

[1] I have worked on such things and, when asked to improve the
    interactive response times from ten minutes to ten seconds,
    I've cheerfully offered to provide code that would run at
    least a thousand times faster, provided I was allowed to
    implement the entire thing from scratch.  Getting the
    desired performance is easy, as long as the original design
    is sane.  Mucking around with optimisation is a waste of
    time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20040427/b85d7c00/attachment.sig>