Cyclomatic complexity vs performance

Question

As far as I understand the concept, CC is determined by how many nested branched logic the given method have. It can be refactored to checking the opposite of original predicate and calling return. For example:

void Foo()
{
  if (predcate0)
  {
    if (predicate1)
    {
      // some code
    }
  }
}

can be refactored to

void Foo()
{
  if (!predicate0) return;

  if (!predicate1) return;

  // some code
}

but the thing is, following the branch predicate0 && predicate1 will generate less cache misses in C++ if this path will be taken much more frequently.

Obviously I intentionally simplifying the code. For example there can be dozens of predicates and things like one predicate dependency on another predicate.

What to do in this case? Should I throw away performance for better readability?

Answer 1

Unless you really need that performance, always prefer better readability.

The biggest performance wins do not come from micro-optimizations, but from algorithmic complexity improvements, and from other ways to avoid doing unnecessary work. Not doing something is always faster than doing something as fast as possible. Cleaner code makes it easier to spot such opportunities.

If you do need that performance, and can prove with a profiler & benchmarking tools that this change will give you that performance, then of course go for it. But you are still at the mercy of your compiler to get machine code that is branch prediction friendly. The compiler might suddenly deduce that a branch that it previously considered unlikely is in fact likely, or vice versa. To get around this, try to look into profile-guided optimization and/or annotations and compiler hints that let you unambiguously mark a branch as likely or unlikely.

Answer 2

If you don't already know for sure that you should throw away readability for performance because you have a performance problem and you have profiler data proving that the problem lies here, then definitely throw away performance.