Is micro-optimisation important when coding?

Question

I recently asked a question on Stack Overflow to find out why isset() was faster than strlen() in PHP. This raised questions around the importance of readable code and whether performance improvements of micro-seconds in code were worth even considering.

My father is a retired programmer, and I showed him the responses. He was absolutely certain that if a coder does not consider performance in their code even at the micro level, they are not good programmers.

I'm not so sure - perhaps the increase in computing power means we no longer have to consider these kind of micro-performance improvements? Perhaps this kind of considering is up to the people who write the actual language code? (of PHP in the above case).

The environmental factors could be important - the Internet consumes 10% of the world's energy. I wonder how wasteful a few micro-seconds of code is when replicated trillions of times on millions of websites?

I'd like to know answers preferably based on facts about programming.

Is micro-optimisation important when coding?

My personal summary of 25 answers, thanks to all.

Sometimes we need to really worry about micro-optimisations, but only in very rare circumstances. Reliability and readability are far more important in the majority of cases. However, considering micro-optimisation from time to time doesn't hurt. A basic understanding can help us not to make obvious bad choices when coding such as

if (expensiveFunction() || counter < X)

Should be

if (counter < X || expensiveFunction())

(Example from @zidarsk8) This could be an inexpensive function and therefore changing the code would be micro-optimisation. But, with a basic understanding, you would not have to, because you would write it correctly in the first place.

Answer 1

There's micro-optimisations and micro-optimisations. In VB (both VB6 and VB.NET, but ignoring the IsNullOrEmpty offering from the framework) I always use Len(str) <> 0 rather than str <> "". However, I normally don't "fix" others code where they've used the latter.

Yes, the latter is more readable, but, in this case, the former is not unreadable.

Performance should be a consideration when designing the code, but not at the detrement of readability and maintainability.

Answer 2

I started programming nearly 31 years ago, where memory and CPU are scarce. Maybe this is why I agree with your father.

I do believe a good coder needs to worry about optimisation in every line of code. But I would add to this sentence: as much as it worths and always trying to favor readability over optimisation in places where computations are not critical.

For example, in another thread, a guy asked about the code below, which solution he would choose: CPU or Memory.

public class Main {

    public static int totalRevenue;
    public static int totalProfit;

    public static int option1(int numSold, int price, int cost) {
        // Option 1 (memory)
        totalRevenue += numSold * price;
        totalProfit += numSold * price - numSold * cost;
        return numSold * price;
    }

    public static int option2(int numSold, int price, int cost) {
        // Option 2 (time)
        int saleRevenue = numSold * price;
        totalRevenue += saleRevenue;
        totalProfit += saleRevenue - numSold * cost;
        return saleRevenue;
    }
}

This code generates the following bytecode:

public class Main {
  public static int totalRevenue;

  public static int totalProfit;

  public Main();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static int option1(int, int, int);
    Code:
       0: getstatic     #2                  // Field totalRevenue:I
       3: iload_0
       4: iload_1
       5: imul
       6: iadd
       7: putstatic     #2                  // Field totalRevenue:I
      10: getstatic     #3                  // Field totalProfit:I
      13: iload_0
      14: iload_1
      15: imul
      16: iload_0
      17: iload_2
      18: imul
      19: isub
      20: iadd
      21: putstatic     #3                  // Field totalProfit:I
      24: iload_0
      25: iload_1
      26: imul
      27: ireturn

  public static int option2(int, int, int);
    Code:
       0: iload_0
       1: iload_1
       2: imul
       3: istore_3
       4: getstatic     #2                  // Field totalRevenue:I
       7: iload_3
       8: iadd
       9: putstatic     #2                  // Field totalRevenue:I
      12: getstatic     #3                  // Field totalProfit:I
      15: iload_3
      16: iload_0
      17: iload_2
      18: imul
      19: isub
      20: iadd
      21: putstatic     #3                  // Field totalProfit:I
      24: iload_3
      25: ireturn
}

For the sake of understandability, 'iload_' load data from stack and 'istore_' save data into stack.

It's easy to notice that you really saved one memory allocation in one solution spending more CPU cycles. That kind of question may arise even for experienced programmers.

But there is a catch in this example: stack memory is pre-allocated in blocks, not at byte level. Each time a thread runs, it will allocate a certain amount of memory to use in stack operations. So unless you are lucky enough to have these 4 bytes overflow your stack (and requiring you to setup a larger stack size), you will be ending up spending the same memory amount to run both examples. But in the second one, you are spending more cycles doing math calculations and your code is much less readable.

I brought it here to give a sample that discussing about optimisations in small portions of code is not evil. Some guy closed that question pointing to this thread. But this thread don't answer that specific question. It only discuss about "don't worry about optimisation". And due to this stupid mantra, people feel that is right not go to deep understanding.

There is a reasonable answer to that question, and maybe one can even give a better answer about the internals. Once learned, a good programmer will be able to repeat that pattern instinctively, and will become a better programmer. Programmers must have critical thinking about their code and must try to understand, as much as possible, how machine will process it.

I'm not advocating here that we all need to optimize little things. Remember that I recommended to favor readability over micro-optimisations.

I just believe that repeating the mantra "don't worry about optimisation" don't make things better. It only make programers lazy. Programmers must be instigated to know how things work behind the scenes. This way people can pursue to write better code, and wisely choose when not to optimise.