You can do all the optimisations you want, but at the end of the day your application will spend 99% of its time waiting for I/O, waiting for data to come in from disk, from the database, waiting for messages back from other systems, even getting bored while it waits to retrieve from slow memory.  In most cases the developer can almost forget CPU cycles at all.  Of course, that doesn't mean ignore silly things like tight loops with no Thread.sleep() call, but most people optimize too early, spending more time on optimization than the design of the solution so it is easy to maintain.

Tip: If you are a new developer who can barely program a stick to be a stick, don't consider optimization of the source code at all until after you have finished and are about to get your code reviewed.

A real world example can illustrate this rule further:

Latham was always harping on about the number of CPU cycles certain operations took versus others.  The customer loved the efficiency talk so much that Latham got put in charge of writing the core of our system – an object cache.  It was only after Latham left that we realised that to remove a single entry from the cache it had to do a sequential walk of the keys.  When the first cache cleanup happened one hour after system startup, the system completely blocked for ten minutes and nobody could work out why.  All the optimizations in the world won't save you if your design is rubbish”.

Of course, don't write silly code that loops without sleeping, like in the following example, which will take 100% CPU unless you add an appropriate sleep:

canRun = true;
for (;canRun;)
{
    if (triggerFile.exists( ))
    {
        // process it
        :
    }
}

A small sleep of a quarter of a second is an infinite rest for the CPU:

canRun = true;
for (;canRun;)
{
    if (triggerFile.exists( ))
    {
        // process it
        :
    }
    try{Thread.sleep(250);} catch {InterruptedException e};
}

Exception: The few developers who write library code that dozens will be using should consider performance a lot, remembering that good performance will come from the design just as much as the code.

Optimisation should only be done once all the parts of the complete solution are clear.

blog comments powered by Disqus